[CentOS-virt] Xen Version update policy

Thu Dec 12 14:25:56 UTC 2019
George Dunlap <dunlapg at umich.edu>

On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange <kevin at steadfast.net> wrote:
> By supporting only even numbered releases as is the case now, it has not
> been possible to do hot migration based upgrades which means that we
> have to do full reboots of our entire environment every so often.  Right
> now we're running on Xen 4.8 and transitioning to 4.12 directly.  We
> skipped 4.10 because we felt that 4.12 has been out and stable for long
> enough.  Ideally if every major build of Xen were provided we would
> transition by hot migrations up to the next release periodically and
> stay on a security supported release each time one is going toward EOL.
> Personally I would love to see at the very least transitional packages
> for each Xen version available to allow for easier hot migrations to the
> latest release, under the assumption that such migrations are considered
> "supported" upstream.  I believe you said this was to be expected in a
> previous conversation we had on IRC.

The original purpose of only doing every other release was to make
sure that maintenance of the packages wouldn't take too much of our
time; but I think at the current state of things, updating ever
release should be fine.  (Particularly now that we've spread out
releases again.)

> I don't really think we should drop a release before its security
> support ends, unless we have *really clear* communication to repo users
> as to the life cycles of these builds in advance.

Indeed, the purpose of this email is in fact to make such a clear
communication.  Citrix (i.e., Anthony & I) have committed to providing
up-to-date packages for one version at a time; this is meant to give
people input into which version that is.  The Virt SIG cannot as a
whole commit to supporting releases until security support ends unless
others step up and make commitments to do so.

> I get why providing updates for 5 major releases concurrently is
> prohibitive for the entire security support period, though if it were
> more automated, maybe it would be easier to manage.

Indeed; I think the main barrier to having the whole thing automated
from xen.git/staging-VV to mirror.centos.org is testing.  If we had at
least a reasonable subset of automated testing between buildlogs and
mirror, I'd feel comfortable with an automated push.  Alternately, if
people were comfortable with "the community has 1 week to test and
object before an automated push happens", we could do that too.