cloud August 2019

cloud@lists.fedoraproject.org

6 participants
15 discussions

Re: [Xen-devel] Criteria / validation proposal: drop Xen
by Adam Williamson 08 Nov '19

08 Nov '19

On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote: > On Thu, 2019-07-11 at 21:43 +0100, Peter Robinson wrote: > > > On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote: > > > > It's worth noting that at least part of the justification for the > > > > criterion in the first place was that Amazon was using Xen for EC2, but > > > > that is no longer the case, most if not all EC2 instance types no > > > > longer use Xen. > > > > > > I don't know where you got that particular piece of information. It > > > isn't correct. Most EC2 instance types still use Xen. The vast majority > > > of EC2 instances, by volume, are Xen. > > > > Correct, it's only specific types of new hypervisors that use kvm > > based, plus new HW like aarch64. > > > > That being said I don't believe testing we can boot on xen is actually > > useful these days for the AWS use case, it's likely different enough > > that the testing isn't useful, we'd be much better testing that cloud > > images actually work on AWS than testing if it boots on xen. > > Yeah, that's where I was going to go next (there has already been a > thread about this this morning). If what we care about is that Fedora > boots on EC2, that's what we should have in the criteria, and what we > should test. > > IIRC, what we have right now is a somewhat vague setup where we just > have 'local', 'ec2' and 'openstack' columns. The instructions for > "Amazon Web Services" just say "Launch an instance with the AMI under > test". So we could probably stand to tighten that up a bit, and define > specific instance type(s) that we want to test/block on. OK, so, to move forward with this (and looping in cloud list): does someone want to propose a set (ideally small - 2 would be great, one Xen and one non-Xen, if we can cover most common usages that way!) of EC2 instance types we should test on? With that, we could tweak the criteria a bit to specify those instance types, tweak the Cloud validation page a bit, and then drop the Xen criterion and test case. Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 5

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

26 Aug '19

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2019-08-28 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: [atomic-announce] Fedora Atomic 29 EOL date?
by Dusty Mabe 25 Aug '19

25 Aug '19

On 8/24/19 6:27 AM, Feilong Wang wrote: > Hi team, > Hi Feilong! I'm adding in Spyros who has worked with us in the past on Atomic Host and Magnum. > Could you please help me understand when will be the EOL date for Fedora Atomic 29? I understand generally it takes 13 months. But given Fedora Atomic 29 -> Fedora CoreOS 30 is a big jump, is there any special considering for this case? Fedora 29 Atomic Host will follow the EOL schedule for Fedora 29. It will EOL approximately a month after Fedora 31 is released. Fedora 31 is scheduled to be released at the end of October, so the EOL for Fedora 29 will probably be around the end of November. > > The background is OpenStack Magnum is using Fedora Atomic as the base operating system to deploy Kubernetes cluster, but because of the big change from FA29 to FCOS 30, we haven't got enough resources on this work. So it would be really helpful if the Fedora Atomic/CorOS community can help me understand the roadmap and plan. Thank you very much. > The Fedora CoreOS preview release is out now. We're hoping to bring that to stable ASAP but we've got some things we'd like to finish before we make that declaration. The best thing that can be done is to get some experience trying out OpenStack Magnum on Fedora CoreOS so that we can get in fixes now before we declare stable. We'd like to work with you more closely to make sure the transition is smooth for the Magnum project. Can you all share some time/resources to work with us to make sure we smooth out any wrinkles? Dusty

1 0

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

20 Aug '19

1 0

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

19 Aug '19

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2019-08-21 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

Fedora 30 cloud image inline_data
by Thomas Meyer 14 Aug '19

14 Aug '19

Hi, As the base image has a lot of small files, did someone test what is the influence of setting ext4 feature inline_data? Are there other reasons why this feature is not active by default? And: Why are there so many duplicate files in the cloud image? Most of them seem to be from pycache and the filename ends in .opt-1.pyc and an equal file ending in .pyc Would it be possible to add an extra step after creating the cloud image to hard link all duplicate files or what would speak against that? With kind regards Thomas

2 1

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

12 Aug '19

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2019-08-14 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] Xen / EC2 release criteria proposal
by Adam Williamson 12 Aug '19

12 Aug '19

On Sat, 2019-08-10 at 20:12 +0200, Dridi Boukelmoune wrote: > Sorry for the top posting, "smart" phone... > > What about Qubes OS? Isn't their dom0 using xen, based on Fedora? > > Do they use Xen as packaged by Fedora? If not, couldn't they contribute > whatever they do that Fedora doesn't here? > > It might be worth getting in touch with them. They look like a significant > Xen user, on Fedora. I have no idea, but those seem like reasonable questions. I'll see if I can track down a contact point for them. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Xen / EC2 release criteria proposal
by Adam Williamson 11 Aug '19

11 Aug '19

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." 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. 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." 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud August 2019