Proposal: Implementation of Server Roles

Fri Jun 27 15:25:43 UTC 2014

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

On 06/26/2014 02:59 PM, Miloslav Trmač wrote:
> Hello, 2014-06-19 16:43 GMT+02:00 Stephen Gallagher
> <sgallagh at redhat.com <mailto:sgallagh at redhat.com>>:
> 
> Please see the design page I've written at 
> https://fedorahosted.org/rolekit/wiki/Design/RolePackaging and
> comment on it here.
> 
> The targets are named fedora-*, but the directory is
> /etc/server-role (no fedora); should this be consistent?  “Stop
> wasting our time” is a perfectly acceptable answer :)  If we did
> want this unified, I’d slightly prefer a fedora-less naming (to
> make this easier on both derived and non-derived distributions).
> 

My intention there was to make the design non-fedora-specific, but
make it clear that the roles we're installing are clearly for Fedora
and probably won't work on other platforms without modification.

> If we go the route of configuration on first boot, we need to be
> sure the error handling is workable: unlike simply running a script
> at (role deploy) time, which can just write to stderr and (exit 1),
> this is not quite as automatic.  How will rolekit find out that the
> configuration step failed, and why?  Perhaps “rolekit would check
> the status of the unit” (when/triggered by what?), and “the unit
> must write sufficient information to journal /associated with the
> unit/”?
> 

My intention is that all of the roles' first-start scripts will have
to be After=rolekit.service so that as part of their output they will
have to signal rolekit about success or failure and can carry a
payload with their error details.

I've also been toying with the idea that we should require roles to
include a journald messageid specific to the role, to make it easier
to track the logs all the way through. This won't be an F21 target, as
I need to talk to the journald devs about whether there's any way to
get journald to add a messageid automatically to messages generated by
any descendent of a unit (or just track them all the way through). I
suspect this isn't available today.

> Tangentially, I’d like the configuration submitted to rolekit 
> (/etc/server-roles/setup/$ROLENAME.config) archived on the system 
> post-deploy, to make “throw away local modifications and redeploy”
> or “what changed on the system since role deployment?” possible.
> That’s fairly independent from the role packaging spec,
> though—rolekit can be saving these anywhere else than
> /etc/server-roles/setup and the roles don’t need to know about the
> existence of the archive.

Well, this information will have to be fully-recoverable from the API.
So yes, it's implicit that this file's content will be stored and
retrievable, though we'll probably do so in a way that's more
"regenerate with identical values" and less "copy the exact file
somewhere".