On Wed, 19 Mar 2014 09:47:20 -0400
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
...snip...
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.
I agree with these, but we may not want to '1.0' the api until we are
further along?
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
It gets this from the fedora-release-server? or ?
* staging_roles: list of object references to Roles that have been
pre-loaded but not yet configured
This it can get from installed packages or a file.
* active_roles: list of object references to deployed Roles
* version: API version
* methods:
Ditto.
...snip...
== 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.
Should we try and rope in the firewalld maintainer(s) here?
They may have some ideas on how to do this so it causes the least
amount of pain.
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.
I think it's a good start! :)
kevin