2014-03-19 14:47 GMT+01:00 Stephen Gallagher <sgallagh@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 all roles.

(I.e. the universal Role in the proposal doesn't even have a DeployRole method.)

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
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)?

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.)

* 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.)

* 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.)

* methods:
  * GetFirewallPorts: list of port/protocol pairs that the Role needs

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 clients.

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 
See above.
  * 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.

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
general case.

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.