Fedora Server Role D-BUS API Design Discussion

[Miloslav Trmač]

2014-03-19 14:47 GMT+01:00 Stephen Gallagher <sgallagh at 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
 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)?

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



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


* 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
>
role.Redeploy(settings)
>
?

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.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140324/8c219a4e/attachment-0001.html>