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@xxxxxxxxxxxxx | www.steadfast.net _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos-virt
