-----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(a)redhat.com <mailto:sgallagh@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".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlOtjPcACgkQeiVVYja6o6Ok1ACfQWOx6jyDeMOUYwIcdhbhck1Z
vZcAmwT9sUw6yisa5hR5Q9bViXTrbii2
=RcOH
-----END PGP SIGNATURE-----