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 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-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/cloud@xxxxxxxxxxxxxxxxxxxxxxx
