Re: [Xen-devel] Xen / EC2 release criteria proposal

[Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel