-----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-----