Proposal: Implementation of Server Roles

[Stef Walter]

On 20.06.2014 20:47, Simo Sorce wrote:
> 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.

Because we deeply care about:

 * Resource information (cgroups)
 * Journal information (units/services)
 * The state of all services in a role (via systemd)

And more. A Role shouldn't just be running wild and free on a system. We
need to be able to identify what is part of that role and what is not.

Yes, another way to do this would be containers. But service information
for a role is the bare minimum.

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

Yes, I think so. We should come up with something standard and useful
here. But more to the point, just staring at a spinning cursor for 10
minutes while IPA is doing something, isn't a good UI.

Stef