[CentOS-virt] Xen Version update policy

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

On 12/2/19 11:08 AM, Kevin Stange wrote:
> 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.

I realized I didn't respond in any way to rate the options as requested.
I don't really support any configuration that doesn't provide
overlapping support for at least two versions simultaneously, so I've
added my own options.  Sorry!

1: -1
1a: -1
1b: -1
1 + 1a + 1b: +2
2: -1
3: -1
2 + 3: +1
4: -1
4a: -1

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