<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">(I apologize for getting to this so late.)<br><br></div><div class="gmail_quote">2014-01-27 19:33 GMT+01:00 Kevin Fenzi <span dir="ltr"><<a href="mailto:kevin@scrye.com" target="_blank">kevin@scrye.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* The roles use cockpit to manage and configure the server role post<br>
install.</blockquote><div><br></div><div>Cockpit should be <i>a</i> mechanism, but not the only mechanism: fully-automated, kickstart-driven installs need to be possible. One thing that would work is an executable (fedora-role-deploy?) that accepts a possibly empty kickstart-like service-specific "deployment configuration"; kickstart can invoke this directly, perhaps with a here-doc, and cockpit can generate the configuration from a GUI and call that executable. To get even more fancy, fedora-role-deploy could interactively ask if something is missing in the deployment configuration, but that's perhaps inviting too much complexity.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * We create a new fedora-server-$role package for each role. This role<br>
package contains the 'glue' we add to turn this into a fedora server<br>
role from just a install with the packages and local config. We will<br>
need to come up with guidelines and what these packages will contain,<br>
but:<br>
<br>
7. We may have a fedora-server-base or fedora-server-common package<br>
to contain common/base stuff all roles need/user and make the role<br>
packages require it. We would need to be very careful about updates<br>
of this however.<br></blockquote></div><br></div><div class="gmail_extra">Ability to cleanly upgrade is a significant concern here. I think the worst case is a major update to something like a database, involving a format change, where you need to keep the old version running to do a data dump, and have the new version installed at the same time to receive the data dump. That would require:<br>
<ul><li>The old and new version of the underlying software (not necessarily the role) need to be parallel-installable. (This does not mean that <i>every</i> two versions of the underlying software need to be parallel-installable.)<br>
</li><li>A role package that defines the new version needs to be installable while the old version of the underlying software is still running. So, no Conflicts:, at least not always. To extend this, the role system might simultaneously want to still be able to handle the old version of the role, so that e.g. monitoring or backups still work while the dump is in progress.</li>
</ul></div><div class="gmail_extra">Another desirable feature would be to have a non-destructive upgrade opportunity: install a newer version of the role package, ask it to do an upgrade, and have the role package refuse an upgrade because it would lead to data loss (or require non-trivial downtime or administrator's manual involvement).<br>
<br></div><div class="gmail_extra">So, I'm leaning towards a design where fedora-server-$role is not a package for a <i>specific version</i> of a role, but for <i>all past versions</i>. Therefore:<br><ul><li>The user can always (yum update) a role package, non-interactively, without actually deploying an updated version of a role.</li>
<li>"Minor" updates (no functionality loss, no human involvement) could happen automatically from a %post or %posttrans script.<br></li><li>(fedora-role-deploy --upgrade) or something similar could be used in an interactive context (CLI / Cockpit) to actually perform a major update, with the above-mentioned ability of a role to perform a feasibility check, to ask for more information, or to confirm that the administrator can accept a downtime needed for non-trivial migration (asking interactively or using an updated deployment configuration file provided as input).<br>
</li></ul></div><div class="gmail_extra">Downsides:<br><ul><li>We would need another mechanism to notify the user that the interactive package update is insufficient and (fedora-role-deploy --upgrade) needs to be run. (Or would we limit the major upgrades only to new Fedora Server releases?)</li>
<li>fedora-server-$role could not depend on versions of the underlying packages that it supports; it would need to install them from fedora-role-deploy in the worst case. (In the common case, the user would ask for a $role comps group, and get both fedora-server-$role and the appropriate versions of the underlying packages.)</li>
</ul></div><div class="gmail_extra">What do you think?<br></div><div class="gmail_extra"> Mirek<br></div></div>