[CentOS-virt] Xen Version update policy

Mon Dec 2 17:08:37 UTC 2019
Kevin Stange <kevin at steadfast.net>

On 11/28/19 12:12 PM, George Dunlap wrote:
> Hey all,
> This mail has been a long time in coming, but with the upcoming
> expiration of security support for Xen 4.8, it's time to start thinking
> about what our update policy will be for the Xen packages in general.
> Citrix is committed to officially supporting one Xen version at a time
> through the CentOS Virt SIG.  (Others in the community are welcome to
> support others.)  But we'd like input as to which version the community
> would like to be supported at any one time.
> Please express your opinion on each option by replying as follows:
> -2: This is a bad idea, and I would argue against this
> -1: I'm not happy with this, but I wouldn't argue against this.
> 0: No opinion.
> 1: I'm happy with this, but I wouldn't argue for it.
> 2: This is a great idea, and I'd argue for it.
> There are several possible options:
> 1. Always support the newest option.  This means we get all the newest
> features from Xen in the Virt SIG by default; but also means we get all
> the newest bugs.
> 1a. Always support the newest option once it has at least one point
> release.  This balances the newness with a bit of extra testing.
> 1b. Always support the second-to-newest version (e.g., when 4.13 comes
> out, switch to 4.12.x)
> 2. Always support the oldest security-supported version.  This means we
> get the most stable version of Xen; but it does mean it is several years
> behind as far as features go.  It also means that further bugfixes do
> not happen automatically, and further bugs found will need to be
> 3. Always support the oldest fully-supported version.  Reasonably
> stable, reasonably old, still gets bugfixes.
> 4. Support a version until it's out of security support, then jump to
> the newest version.  This minimizes the number of upgrades required
> (although may make each upgrade more painful).
> 4a.  Support a version until it's out of full support, then jump to the
> newest version.
> Any other options?
> For my part, I think 1a, 1b, and 3 are all reasonable options.

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.

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.

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.

I think the keys are making sure that the lifecycles are clearly
communicated in advance and that there's a fairly reliable path for
people to move up to the latest version that is suitable for production
use.  So I wouldn't say no to a 1 + 1a + 1b configuration, with the idea
that 1 is effectively "testing" to become stable at 1a, then
simultaneously always provide 1b as well.  That would, by my
interpretation mean there are always 2 or 3 supported versions.  Right
now, 4.12 "stable" and 4.11 "legacy" would be supported.  When 4.13
comes out, 4.13 would be "testing" but would be fully maintained with
security and point release updates.  When 4.13.1 is released it would
become "stable," 4.11 would be deprecated and 4.12 would become "legacy."

However, during the transitional period maybe we need to commit to
supporting 4.10 until its security support ends.

Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
kevin at steadfast.net | www.steadfast.net