Proposal: Implementation of Server Roles

[Stephen Gallagher]

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

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


>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOkLUIACgkQeiVVYja6o6MiPgCfbXiFBr91p07xHukpO9b0WVV2
+S0An110LX8vARQxwJMmRHGLiK/MkQ9o
=A7In
-----END PGP SIGNATURE-----