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. -George
On 12/12/19 8:25 AM, George Dunlap wrote:> On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange <kevin at steadfast.net> wrote: >> 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.We should probably provide a matrix of which Xen versions are offered by the SIG, who is maintaining them, and when they will last be supported (roughly if it's not 100% clear due to upstream scheduling). There's a bunch of legacy Xen4CentOS and other confusing Xen docs in the CentOS documentation that need to be cleaned up, removed, or unified. I'm happy to continue working on and testing releases for whichever branch I'm currently on (which is 4.8 right now, but I'm moving on since upstream is done with security support). However I can't make commitments to support or test versions I am not actively running in production, nor provide specific life cycle guarantees. I made that mistake with 4.4, though meltdown was an extenuating circumstance; I simply couldn't handle that kind of backport myself. That said, I *may* offer continued support and testing for 4.12 when 4.14's release pushes it out of maintenance by Virt SIG. That's something I'm going to have to play by ear, I guess. I don't want to burden Steven Haigh any, but I wonder if there's a way we could combine some of our efforts to make both "Xen made easy!" and the Virt SIG Xen easier to manage. -- 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
On 2019-12-13 04:54, Kevin Stange wrote:> I don't want to burden Steven Haigh any, but I wonder if there's a way > we could combine some of our efforts to make both "Xen made easy!" and > the Virt SIG Xen easier to manage.I've been thinking about this for a while. The problem has been the workflows between myself and the SIG are so far apart, its hard to look at how to merge them. I have full CI between my own git and packages to the mirrors - which is good, but has its down sides. I also don't have the restrictions of the CentOS build system to deal with - which is great for my workflow ;) I'm prepping packages for CentOS 8 now - but its exposing quite a number of problems around the main toolsets for Xen - and instead of just adding my own patch and moving on (ala Fedora's Xen packages), I'm trying to get fixes in upstream where possible. My todo list currently includes: 1) Replace all #! that include env python to a specific python version/binary. ie /usr/bin/python or /usr/bin/python3. The configure portions of this are complete, but the scripts need to be altered to have the detected python version populated. 2) There's no brctl in CentOS 8. The network scripts need to be re-written to use 'ip' instead. To maintain compatibility, the network scripts need to support both brctl and ip commands and use whichever is present on the system. 3) UEFI support needs to be tested. The preferred UEFI boot method for Dom0 is to use grub to then boot Xen - but this needs to be tested. So while me moving to try and get these fixed upstream is great - it should make everyone's job easier in the long term. Although I have the same problem as the SIG - there's just not enough people to test / patch stuff. The more we deep dive into 4.13, the further away I can see the release happening :( -- Steven Haigh ? netwiz at crc.id.au ? https://www.crc.id.au