-----BEGIN PGP SIGNED MESSAGE-----
On 03/24/2014 05:02 PM, Miloslav Trmač wrote:
2014-03-19 14:47 GMT+01:00 Stephen Gallagher <sgallagh(a)redhat.com
2) We do not need to have a single generic API that will work for
any conceivable Role. We've identified in the past that the
selection of Featured roles will (for the conceivable future)
remain a small, manageable list. For this reason, it is acceptable
for the deployment and post-deployment configuration APIs to be
entirely different between two roles. However, some functionality
such as the backup and firewall queries should be stable between
(I.e. the universal Role in the proposal doesn't even have a
I don't think this is efficient—every "universal" client (and there
will be at least one or perhaps two, fedora-role-manage,
anaconda/initial-setup kickstart processing) would have to build
essentially the same abstraction over these role differences.
Wouldn't it be cleaner to have generic ValidateSettings(settings)
DeployRole(settings) as the abstraction used by the "universal"
clients (with "settings" possibly having some universal settings,
like our favorite firewall_enabled_after_deploy, but mostly
role-specific, only using a standard format, perhaps JSON or some
object graph with similar capabilities)?
That's an idea. I'm not sure it's doing anything other than moving the
problem to the settings object instead of the method call, but *shrug*.
The kickstart processor would only decode JSON and pass it to the
API without understanding the contents; the Role-specific GUIs
would have specific knowledge of settings to set—or specific Roles
could even provide helper APIs, say
AutodetectDefaultReplicaControllerSettings() to query the network
and give the GUI information about what the role thinks is
appropriate for the specific situation.)
/org/fedoraproject/server/ServerRoleManager: * properties: *
all_roles * staging_roles * active_roles
Isn't this redundant with the per-role properties specifying the
role's state? (Even if it were redundant, it wouldn't be a huge
deal—just a little work that we might be able to avoid.)
Yes, see Jan's response as well. Better to leave that to the D-BUS
/org/fedoraproject/server/role/$ROLE: * properties: * loaded:
Bool: whether the packages are installed * deployed: Bool:
whether the Role has been deployed
(Nitpicking? Rather an enum to eliminate possibilities of
paradoxes like deployed & ~loaded.)
See also Jan's reply. We also need a "deploying" state, so maybe an
enum is the right idea here.
* methods: * GetFirewallPorts: list of port/protocol pairs that the
I'd much rather have FirewallRestriction enum (LocalhostOnly,
Unrestricted, Complex) or something like that, or, if we decided
to depend on firewalld, an object reference to a firewalld service.
Roles will be asking for ICMP, new IP protocols, and whatnot, and
we don't need to start with that complexity in the API and the
Sorry, that was a little thin. Could you go into a bit more detail
e.g. /org/fedoraproject/server/role/DomainController * methods: *
DeployPrimaryDomainController: Set up the first domain controller
in the domain. * DeployReplicaDomainController: Add a new replica
domain controller to the domain
* AddCertificateAuthority: Add a certificate authority to
this domain controller * EnableDisableDNS: Enable or
disable the DNS server on this server
This would of course work. A philosophical question, though: would
we rather move to closer to the "cattle" model, i.e.
settings = role.GetCurrentSettings() settings.enableDNS = False
A "redeploy" is more work for the role, having to compare the
settings with current deployment and apply them, but it also ensure
that that code path works; with the individual configuration
modification operations, the roles could still provide a
GetCurrentSettings method, but we would have two completely
separate paths (EnableDisableDNS vs. Deploy) to test, and the risk
of them diverging.
Hmm, but redeploy may not be possible (or idempotent) for all possible
setting changes. For example, if we deploy FreeIPA with a built-in
Certificate Authority, we can't redeploy without it, since the whole
system will have been predicated on it. (Not without having a
mechanism for redeploy being effectively a complete migration...
possibly between VMs or containers?)
1) How do we handle configuring the Firewall? I think we want to
have a Firewall object
(/org/fedoraproject/server/RoleFirewallManager) available to query
the firewall as a whole, but we may also want to be able to view
and apply firewall rules from the Role objects directly. (Note: I'm
not suggesting we need a complete firewall solution here. This
should be a wrapper that deals only with the Roles). Firewalld
already provides a more comprehensive firewall interface for the
If we provide a limited firewall facade so that Fedora Server can
work without firewalld, IMHO it should literally be the simplest
possible "role.FirewallPreventsNonLocalhostAccess" value; not even
listing the ports involved. If we provide something closer to a
full-featured D-Bus API firewall, we might just as well require
firewalld directly instead of writing a firewalld competitor.
I think my original statement failed to get my point across, but I
think I was pretty much saying the same thing you are. First of all,
we *did* agree to use firewalld as the proper solution. I just meant
that in terms of defining the Role-firewall interop, it should *not*
try to be a complete set of firewall rules. For that, we should allow
a Role to have a 'managed_firewall=False' setting or something like
it, and that admins would be expected to handle the firewall
appropriately through firewalld/iptables. But if we *are* managing it,
it's probably acceptable for it to be essentially either blocked or
allowed on a whitelist of interfaces ('lo' being just a special case).
Anyone requiring more control than that should set
managed_firewall=False and do it themselves.
 The reason for this being so that UIs can note that this is under
manual control and also so that later Role upgrades don't attempt to
open or close ports.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----