-----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(a)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-meeti...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlMpn+gACgkQeiVVYja6o6Ou5wCeJw5zELa1zwLj++EBf66PKMKh
z6EAn1MOkhPQhY4bj9afTy1of68/QhXR
=xz9N
-----END PGP SIGNATURE-----