Fedora Server Role D-BUS API Design Discussion - cockpit-devel - Fedora mailing-lists

19 Mar 2014


      -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
During this week's Fedora Server Working Group meeting[1], we started
planning out how we want the public D-BUS API to look. I volunteered
to take the discussion to the list so we could start hashing it out
with a wider audience. I'm CC-ing the cockpit-devel list since a lot
of this will affect that project, but I'd prefer to keep replies on
server@lists.fedoraproject.org please (easier to track on one list).
Some pre-conditions/goals (many of these are reminders from earlier
discussions):
1) We want to be able to support two initial clients of this API: the
    Cockpit management console and a local command-line tool (I've been
    tentatively calling it 'fedora-role-manage') A third, future option
    will be to also support remote access to this API via the OpenLMI
    Project.
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.
3) The supported clients should be able to determine if a target system
    supports the deployment of a particular role (for backwards-
    compatibility and architecture differences), but the Role API should
    *NOT* be attempting to dictate the UI experience. UIs should merely
    check whether the role is available and then use a previously-
    developed experience. We don't want to be reimplementing PAM or
    debconf here.
4) The D-BUS API must be stable. If it is likely that the set of input
    required to deploy or configure will change, this should be planned
    for in the design.
5) As it is not possible to plan for all contingencies, the API must be
    versioned such that the clients can determine whether they can
    properly perform the requested actions.
Some initial thoughts on the matter (all are open to discussion):
Standard Objects:
/org/fedoraproject/server/ServerRoleManager:
* properties:
  * all_roles:     list of object references to Roles that can be
                   installed and deployed
  * staging_roles: list of object references to Roles that have been
                   pre-loaded but not yet configured
  * active_roles:  list of object references to deployed Roles
  * version:       API version
* methods:
# These properties and methods should be available and identical on
# all Roles
/org/fedoraproject/server/role/$ROLE:
* properties:
  * version:          API version
  * loaded:           Bool: whether the packages are installed
  * deployed:         Bool: whether the Role has been deployed
* methods:
  * PreloadRole:      Install all necessary software packages for
                      default operation
  * GetFirewallPorts: list of port/protocol pairs that the Role needs
                      open in the firewall
  * PrepBackup:       method to invoke any necessary pre-backup steps
                      (such as running a database dump to a file)
  * GetBackupFiles:   list of filesystem path objects that identifies
                      all data that should be copied by backup software
# Individual Roles should have unique implementations of installation
# and deployment
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
== Open questions ==
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.
I'm sure there are other questions we'll discover out there, but this
email is already running long for an "introduction" to the topic.
[1]
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-18/fedora-meeting-...
...PGP SIGNATURE...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMpn+gACgkQeiVVYja6o6Ou5wCeJw5zELa1zwLj++EBf66PKMKh
z6EAn1MOkhPQhY4bj9afTy1of68/QhXR
=xz9N
-----END PGP SIGNATURE-----