Server Role API

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is languishing a bit and we're running out of time.

I've got some high-level requirements listed at
https://www.piratepad.ca/p/ServerRoleRequirements (copied below,
better formatted on the Piratepad)

We need to define the interface and start implementation soon, as we
only have seven weeks until Alpha freeze.



Requirements:
  * Must be able to install all necessary packages for a Server
RoleRequirements:
  * Must be able to install all necessary packages for a Server Role
    * Using yum/comps "groups" for this is acceptable
  * Must provide a plugin architecture for each available Server Role
  * Must be able to indicate the set of system services that should be
running (based on the current configuration)
  * Must be able to indicate the set of ports that need to be open to
public, private or both types of networks.
  * Must be able to individually open ports presented above on
specific interfaces.
  * Must be able to query the current state of required ports and
system services.
  * Apart from "indicating" properties, the typical uses should also
be in the API provider and not the clients.  Notably, "install and set
up a role", and later "upgrade role" are API calls.
  * (Nice-to-have/future) Must be able to report a list of files for
backup software to key off
  * (Nice-to-have/proposed) List configuration files differing from
defaults installed via RPM and not accounted for by RPM installations;
show diff (if altered) and allow reverting
  * (Nice-to-have/proposed) procfs integration to see processes (and
related services) mapping replaced/deleted executables and libraries
  * Eventually: access to major configuration items (those cockpit
would want to manage in its UI)
    * stefw: I think the cockpit ui for configuring a role would be a
per-role cockpit plugin (ie: likely not via a generic API, via role
specific APIs, and or tools)..
  * Eventually: Monitoring integration (undefined what to integrate
with ATM)
  * The daemon implementing this (important but rarely used) server
role API must exit when not in use.
    * "not in use" means that all DBus clients which have invoked
methods have gone away.
      * What is the plan with openLMI for example?
        * its providers are subprocesses that exit when not in use,
and as such their dbus connections close.

Considerations:
  * The set of Roles will be small. It is not required that we build a
generic API that can handle all possible cases. It is permissible for
individual Roles to have their own custom API.

Cockpit Notes:
  * Likely cockpit will not perform installs against a generic API,
but a per-role tool or API
    * ie: ipa-server-install is very close to what you need to install IPA
  * Likely cockpit will want to see state and status of installed
server roles via a generic API:
    * List of installed roles.
    * What set of systemd services comprise a role
    * Mount points that contain the role's "data"
    * When the role was installed
    * Networking ports and routes required by the role.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN5+ScACgkQeiVVYja6o6Ny1ACfeIBwfl7gTxg+NArukRvDqUb7
CSUAoJRq8yLKl7u5oRwX0bUZM0CKhNVm
=ibGw
-----END PGP SIGNATURE-----