On Sat, 2019-08-10 at 00:53 -0400, Nico Kadel-Garcia wrote: > On Fri, Aug 9, 2019 at 8:57 PM Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > Hey folks! I'm starting a new thread for this to trim the recipient > > list a bit and include devel@ and coreos@. > > > > The Story So Far: there is a Fedora release criterion which requires > > Fedora to boot on Xen: > > > > "The release must boot successfully as Xen DomU with releases providing > > a functional, supported Xen Dom0 and widely used cloud providers > > utilizing Xen." > > How difficult is this to accomodate? So there's two factors behind the idea of dropping support for straight-up Xen domU support: 1. It just doesn't get tested. It's been in the criteria for years and we've had various promises from various folks to test it, but...it just doesn't happen. Each cycle we end up scrambling to have someone test it in a hurry a week before release. Once again after we sent out this proposal people have promised to test it, but...honestly, after the last two go-rounds I'm finding it harder to believe in that. 2. What's the justification for it? Xen isn't our supported virt stack, that's KVM. It is also just not that popularly used by Fedora users in my experience. People ask about running Fedora on VMware, VirtualBox and Parallels a lot, and we don't block on those. Xen doesn't often come up, yet we block on it. > Amaxon Dom0... well, they've got > their own developers tweaking their own kernel, both for their > hypervisors and for Amazon Linux, and they do seem to absorb leding > edge kernel technologies. It's the rest of us, using the other > technologies such as Xen, from the CentOS community, KVM from the Red > Hat commercial community, Virtualbox and VMWAre guests, that I think > are more likely to run into difficulties. KVM we already block on, as it's Fedora's supported virt stack. And yeah, we've never blocked on VirtualBox or VMWare even though they're widely used. So just blocking on Xen seems a little arbitrary. > > We (QA group) had a discussion about removing this criterion entirely. > > That has now morphed into the idea that we should tweak it to be > > focused exclusively on the "widely used cloud providers utilizing > > Xen"...by which we mean EC2. At the time this criterion was invented, > > all EC2 instance types used Xen; now, some still use Xen, and some use > > KVM. > > Commercially, and for developers, they're all still in use. As a > DevOps person, I can appreciate that testing resources are limited. > > > So it seems like this would also be a good opportunity to revisit and > > nail down more specifically exactly what our cloud requirements are. > > bcotton suggested that we require two sample instance types to be > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > like it might be worthwhile - he's promised to get back to me). > > The *tiny* instances are still often used for test environments. Sure, but we can't practically commit to testing every instance type (there's a ton). The aim is, pick a reasonable sample that will give us pretty good confidence that the others will work too. If 'large' works, is 'tiny' likely to not work? And vice versa? This is definitely something we still need to nail down, the types suggested so far are just bcotton's proposal. Perhaps it would make sense to go for smaller types rather than larger ones, as you can envisage a scenario where the larger types are fine but smaller ones have issues due to resource problems or something...of course, we shouldn't pick a type with fewer hardware resources than we actually intend to support... Thanks for the feedback! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
