cloud August 2019

cloud@lists.fedoraproject.org

6 participants
16 discussions

Re: [Xen-devel] Xen / EC2 release criteria proposal
by Adam Williamson 10 Aug '19

10 Aug '19

On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote: > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote: > [...] > > 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). > > > > 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." > > Hi Adam, > > Thanks for bringing this up. It's good to revisit things from time to > time as the world changes. Thanks for the feedback, Matt! > Of the two instances that you propose, neither runs on Xen. The T2 > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor. That'll teach me to trust Ben...;) > To ensure that a Linux based AMI functions across all of the devices > and operating modes of EC2, you need to cover: > > x86 platforms > ------------- > * Xen domU with only PV interfaces (e.g., M3 instances) > * Xen domU with Intel 82599 virtual functions for Enhanced Networking > (e.g., C3 instances running in a VPC) > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances) > * Xen domU with NVMe local instance storage (e.g., virtualized I3 > instances) > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge) > * Xen domU with four NUMA nodes (e.g., x1.32xlarge) > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge) > * KVM guest with consistent performance (e.g., c5.large) > * KVM guest with burstable performance (e.g., t3.large) > * KVM guest with local NVMe storage (e.g., c5d.large) > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter > (c5n.18xlarge) > * KVM guest on AMD processors (e.g., m5a.large) > * KVM guest on AMD processors with maximum NUMA nodes (e.g., > m5a.24xlarge) > * Bare metal Broadwell (i3.metal) > * Bare metal Skylake (m5.metal) > * Bare metal Cascade Lake (c5.metal) > > Arm platforms > ------------- > * KVM guest on Arm with 1 CPU cluster (a1.xlarge) > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge) > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge) > > Not all of these are going to cause an image to fail to boot up to the > point where a customer can SSH in. But a good number of these have > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen). Thanks a lot for the list, it's very helpful. It's also very long, though. :P Still, we can certainly use it as a base. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

1 0

Re: Xen / EC2 release criteria proposal
by Adam Williamson 10 Aug '19

10 Aug '19

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(a)fedoraproject.org> 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

1 0

cloud-init regression F30 cloud image
by Michael Gugino 08 Aug '19

08 Aug '19

Looks like https://bugzilla.redhat.com/show_bug.cgi?id=1596062 has come back based on my testing on GCE. https://pagure.io/cloud-sig/issue/289 logs: https://gist.github.com/michaelgugino/342f08608c4795c8241d38d9a72e3261 related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1644692 Thoughts? -- Michael Gugino Senior Software Engineer - OpenShift mgugino(a)redhat.com 540-846-0304

2 2

Fedora Atomic Host Two Week Release Announcement: 29.20190805.0
by noreply＠fedoraproject.org 05 Aug '19

05 Aug '19

1 0

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 05 Aug '19

05 Aug '19

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2019-08-07 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

Re: [Xen-devel] Criteria / validation proposal: drop Xen
by Ben Cotton 01 Aug '19

01 Aug '19

On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam <elnikety(a)amazon.com> wrote: > > But t3 is not Xen. > That's a good reason to not use it. :-) I picked it to be a small, cheap instance that would represent a potential use case. Is the t2 family Xen? Or the m5? I think it makes sense to write the requirement as "the lastest version of the foo family" just so that we're not updating it every time AWS adds a new version. So I'll defer to you on what's the best option for small-and-Xen. Thanks, BC -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud August 2019