-----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@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".