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?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. > 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. > So, for now, let me propose this as a trial balloon: we rewrite the > above criterion to say: > > "Release-blocking cloud disk images must be published to Amazon EC2 as > AMIs, and these must boot successfully and meet other relevant release > criteria on c5.large and t3.large instance types." > > Notes: > > 1. The test matrix template has an Openstack column, but we never > actually covered Openstack in the release criteria. I think we should > continue to leave it out of the criteria and also remove the column > from the matrix. In the past we tested Openstack boot in the infra > Openstack, but that has gone away or is going away...that means a) we > can't test on Openstack so easily any more and b) a lot of the reason > to bother testing on Openstack is gone. This is up for debate, but if > we believe it's important to test on Openstack and block on working in > that environment we need to have a reliable way to *do* that. > > 2. The test matrix template also has a 'Local' column which is for > testing locally with testcloud, but I don't think we need to > specifically require that to work in the criteria. It's more of a > testing convenience thing, so even if no-one tests on EC2 we at least > test that the image boots in testcloud; testcloud isn't an environment > you'd actually use to do anything practical in. > > 3. I believe this wording is generic enough to cover us if we, e.g., > want to start blocking on CoreOS images. All we have to do is declare > that some CoreOS image is 'release-blocking', and it's instantly > covered by this requirement. As a Fedora user, and a cloud user, this makes complete sense. It gets very expensive in money and manpower to test *)everything*, especialy if you're at the bleeding edge of software development. Well defined test criteria are our friend. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
