During this week’s Fedora Server Working Group meeting, 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’d prefer to keep replies on firstname.lastname@example.org please (easier to track on one list), but if comments are made on this blog post, I’ll forward them along as well.
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.
- 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.
- 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.
- 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.
- 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):
- 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
These properties and methods should be available and identical on all Roles
- version: API version
- loaded: Bool: whether the packages are installed
- deployed: Bool: whether the Role has been deployed
- 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
- 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
- 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.