[CentOS-virt] Xen Version update policy
Kevin Stange
kevin at steadfast.net
Mon Dec 2 17:15:31 UTC 2019
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
More information about the CentOS-virt
mailing list