Proposal: Implementation of Server Roles

[Simo Sorce]

On Fri, 2014-06-20 at 20:31 +0200, Stef Walter wrote:
> On 20.06.2014 14:46, Stephen Gallagher wrote:
> > On 06/20/2014 06:35 AM, Stef Walter wrote:
> >> On 19.06.2014 16:43, Stephen Gallagher wrote:
> >>> I've finally gotten around to putting together my thoughts on 
> >>> how (at a high level) the roles should be implemented. NOTE:
> >>> this is specifically about the Roles as a concept, not the 
> >>> implementation of the logic within the roles, except for a
> >>> couple restrictions I make on input and output format.
> > 
> >>> Please see the design page I've written at 
> >>> https://fedorahosted.org/rolekit/wiki/Design/RolePackaging and
> >>>  comment on it here.
> > 
> >> I like the use of targets a lot. This really fits in well with
> >> how we use systemd in Cockpit.
> > 
> >> But is it required that all services that comprise the role be 
> >> listed in "Wants"?
> > 
> >> For example for IPA, Cockpit has no way to track which 
> >> units/cgroups are part of the IPA role, and representing them. 
> >> That's because there's this awkward ipa.service middleman which 
> >> runs systemd commands on its own instead of declaring
> >> dependencies for systemd.
> > 
> > 
> > Yes and no. I'm fully aware of the FreeIPA special-case. In that 
> > situation, we just need to do "Wants=ipa.service" and trust that
> > this service will start and stop the sub-services appropriately (as
> > FreeIPA currently does).
> 
> This is unfortunate when it comes to building Server Roles into
> Cockpit. Why is the service information in LDAP?

Because FreeIPA is a distributed system, and an admin can, first of all,
see immediately what services are enabled on any server of the
infrastructure w/o having to log in on each of them. The admin can also
turn off a service by accessing any server, and switching it in LDAP,
when the affected ipa server restarts, that service does not (or vice
versa). (we haven't wired an action in LDAP to trigger a service
start/stop on the system yet, but it may be something we want to do in
the future).

> But anyway, I guess the key question that needs to be answered is:
> 
>  * How can Cockpit enumerate the services that comprise a role?
> 
> That's a basic building block that we'll need in order to implement
> roles in Cockpit.

Why do you care exactly what services are enabled ?
I haven't read anything about providing a list of (sub)services from the
Roles but certainly that can be added if it is beneficial.

For IPA I guess for now all you can really do is parse ipactl status or
read via LDAP, not great ways, but then so far IPA does not have any
dbus at all ..

> >>> I will be the first to admit that the "First-Boot
> >>> Configuration" approach is a bit of a hack, but it's a hack
> >>> that will work regardless of installation during anaconda or a
> >>> live system (it defers the configuration step to a systemd unit
> >>> that runs just prior to the first start-up of the role). The
> >>> implication here is strong: while the UI that prepares the
> >>> configuration may be interactive, the content fed into rolekit
> >>> is non-interactive.
> > 
> >> So is there room for the UI to try to setup a role configuration 
> >> and ask the user for changes if the the configuration fails?
> >> This is pretty key to building a good UI. Or are UIs like
> >> Cockpit expected not to use a separate configuration mechanism?
> > 
> > 
> > If the deployment fails, the rolekit API will be back in the
> > "Nascent" state and will have error data available as an attribute
> > on the Role object. So Cockpit will be able to monitor for the
> > D-BUS signal for the error attribute changing and use that data as
> > feedback to the UI.
> 
> So thinking ahead here, if Cockpit were to use such a configuration
> scheme ... we would need the following:
> 
>  * Precise information about which part of the configuration caused
>    the failure, perhaps some sort of property name/identifier.
>  * Translated or translatable messages about the failure.
>  * Textual (and ideally translatable or translated) progress
>    information as the Role is being deployed (ie: the same output you
>    get from ipa-server-install).
> 
> Obviously the above list is incomplete.

I am not sure I can give you the first 2 easily, the latter is a lot of
output, is the quantity/format important ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York