On Fri, 2014-06-20 at 12:35 +0200, 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.
The reason for this awkward command is that we know the list of services
to start only by querying the LDAP server (which needs to start first of
course), and then apparently we cannot change the list of services
easily/reliably anymore as the process of starting IPA is already
started, and changing unit files on the fly is not something systemd
picks up :)
If someone has a good idea on how to start DS, pull the service list,
reconfigure systemd (if necessary) and be able to keep the process going
on reliably I am all ears :)
> 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?
I had the same question...
Simo.
--
Simo Sorce * Red Hat, Inc * New York