On Mon, 2019-05-13 at 16:29 -0600, Lars Kurth wrote:
Hi all,
I am going to step in here with my hat as Xen Project community manager. We had a discussion about this issue as part of last week's community call. I CC'ed a number of stake-holders, which probably should have been on the thread such as ITL (which builds QubesOS on top of Fedora) and Michael A Young (the Xen package manager).
First of all apologies that this issue has lingered so long. Key members of the community were not aware of the issues raised in this thread, otherwise we would have acted earlier. With this in mind, please in future raise issues with me, on xen-devel@, committers@ or the Xen-Fedora package manager. The Xen Community would like to see Fedora running as guest: in fact it would be somewhat odd if there was a Xen-Dom0 package and guest support didn't work. And there are some downstreams such as QubesOS, which depend on this support.
Thanks for stepping in. Of course we always want as much stuff as possible to work, but that does not mean we block the release on it. We certainly want Fedora to work as a guest on VMWare, VirtualBox and Parallels too; we don't block the release on any of those either...
Well, I mean, every few *days* a compose gets nominated for validation testing, and a mail is sent to test-announce. Just check your test- announce archives for mails with "nominated for testing" in their subject lines, and you'll see dozens. Is this not sufficient notification?
We discussed this at the community call and came to the conclusion that we can run regular tests of Fedora RC's as part of our OSSTEST infrastructure. Ian Jackson volunteered to implement this, but there are some questions on a) The installer (which we can handle ourselves) b) When we would trigger a test - aka is there some trigger other than the c) How would results best be reported back to Fedora
Apologies, I am not very familiar with how the Fedora Test group works. Is there some documentation which would help integrate what you to with the test system of another open source project?
b) you can use fedmsg / fedora-messaging: https://github.com/fedora-infra/fedmsg https://github.com/fedora-infra/fedora-messaging A message is emitted every time a compose attempt finishes (on the fedmsg topic 'org.fedoraproject.prod.pungi.compose.status.change': see https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.... for a log of past messages). What you will want to do is listen for completed Branched and Rawhide composes and run tests whenever one completes successfully. This is already exactly what we do to schedule openQA tests; you can crib from the openQA test scheduler: https://pagure.io/fedora-qa/fedora_openqa particularly the fedmsg consumer: https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/consum...
c) ideally it would be good to report to both resultsdb and to the wiki. Again, we already do this for openQA, and you can crib from the code there: https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/report... reporting to ResultsDB might be tricky due to authentication issues, I'm not sure if we ever put the openID auth stuff into production. For wiki reporting you will either have to auth manually every so often or ask Fedora infra for a special token that doesn't expire (this is what we do for the openQA results). Reporting to ResultsDB you do through resultsdb_api - https://pagure.io/taskotron/resultsdb_api - and optionally you can use my resultsdb_conventions - https://pagure.io/taskotron/resultsdb_conventions - which makes it somewhat easier (IMO anyway) and will make your results consistent with those from openQA and Autocloud. Reporting to the wiki you can do through my crazy python-wikitcms library - https://pagure.io/fedora-qa/python-wikitcms . Again, fedora_openqa does all this for openQA results, so you can crib from that. Let me know if you have trouble with this.
from Oracle. On that basis, I'm proposing we remove this Final criterion:
s/Oracle/Xen Project/ I believe?
Perhaps, it's just that it always seemed to be you doing the testing, so they got a bit conflated :)
Can we come to some arrangement, by which such issues get communicated to the Xen Project earlier? Aka me, xen-devel@ or committers@
It would be nice if you could ensure someone from Xen is actually watching the Fedora lists, if working in Fedora is a target for Xen. We *could* try and CC stuff all the time, but imagine if we tried to do that for everybody. But yes, for future conversations of this nature I'll try and remember to include those lists.
"The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen."
and change the 'milestone' for the test case - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - from Final to Optional.
Thoughts? Comments? Thanks!
I would prefer for it to remain as it is.
This is only practical if it's going to be tested, and tested regularly
- not *only* on the final release candidate, right before we sign off
on the release. It needs to be tested regularly throughout the release cycle, on the composes that are "nominated for testing".
Would the proposal above work for you? I think it satisfies what you are looking for. We would also have someone who monitors these test results pro-actively.
In theory, yeah, but given the history here I'm somewhat sceptical. I'd also say we still haven't really got a convincing case for why we should continue to block the release (at least in theory) on Fedora working in Xen when we don't block on any other virt stack apart from our 'official' one, and we don't block on all sorts of other stuff we'd "like to have working" either. Regardless of the testing issues, I'd like to see that too if we're going to keep blocking on Xen...
On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
"The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen."
and change the 'milestone' for the test case - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - from Final to Optional.
Thoughts? Comments? Thanks!
I would prefer for it to remain as it is.
This is only practical if it's going to be tested, and tested regularly
- not *only* on the final release candidate, right before we sign off
on the release. It needs to be tested regularly throughout the release cycle, on the composes that are "nominated for testing".
Would the proposal above work for you? I think it satisfies what you are looking for. We would also have someone who monitors these test results pro-actively.
In theory, yeah, but given the history here I'm somewhat sceptical. I'd also say we still haven't really got a convincing case for why we should continue to block the release (at least in theory) on Fedora working in Xen when we don't block on any other virt stack apart from our 'official' one, and we don't block on all sorts of other stuff we'd "like to have working" either. Regardless of the testing issues, I'd like to see that too if we're going to keep blocking on Xen...
So, this died here. As things stand: I proposed removing the Xen criterion, Lars opposed, we discussed the testing situation a bit, and I said overall I'm still inclined to remove the criterion because there's no clear justification for it for Fedora any more. Xen working (or rather, Fedora working on Xen) is just not a key requirement for Fedora at present, AFAICS.
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. Another consideration is that there was a time when KVM was still pretty new stuff and VirtualBox was not as popular as it is now, and Xen was still widely used for general hobbyist virtualization purposes; I don't believe that's really the case any more.
So...with thanks to Lars / Xen Project for their input, I'm afraid I'm still in favor of this proposal, and still think we should drop the Xen criterion for F31. This wouldn't mean Xen is out of Fedora and we don't care about it any more, or anything like that; it would still be a part of Fedora and we still would like Xen to work on Fedora and Fedora to work on Xen, just like any other non-release-blocking package. It just means we would no longer block releases if it does not work.
Anyone have further thoughts on this? Xen folks, do you object to this really strenuously? If so I guess we could take this to a higher/wider level for more input.
I am in favor of removing the Xen blocking criteria as it has not received the testing it needs and has been a source of conflict for several releases in the past.
Geoff Marr IRC: coremodule
On Mon, Jul 8, 2019 at 10:12 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
"The release must boot successfully as Xen DomU with releases
providing
a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen."
and change the 'milestone' for the test case -
https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
from Final to Optional.
Thoughts? Comments? Thanks!
I would prefer for it to remain as it is.
This is only practical if it's going to be tested, and tested
regularly
- not *only* on the final release candidate, right before we sign off
on the release. It needs to be tested regularly throughout the
release
cycle, on the composes that are "nominated for testing".
Would the proposal above work for you? I think it satisfies what you
are
looking for. We would also have someone who monitors these test results pro-actively.
In theory, yeah, but given the history here I'm somewhat sceptical. I'd also say we still haven't really got a convincing case for why we should continue to block the release (at least in theory) on Fedora working in Xen when we don't block on any other virt stack apart from our 'official' one, and we don't block on all sorts of other stuff we'd "like to have working" either. Regardless of the testing issues, I'd like to see that too if we're going to keep blocking on Xen...
So, this died here. As things stand: I proposed removing the Xen criterion, Lars opposed, we discussed the testing situation a bit, and I said overall I'm still inclined to remove the criterion because there's no clear justification for it for Fedora any more. Xen working (or rather, Fedora working on Xen) is just not a key requirement for Fedora at present, AFAICS.
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. Another consideration is that there was a time when KVM was still pretty new stuff and VirtualBox was not as popular as it is now, and Xen was still widely used for general hobbyist virtualization purposes; I don't believe that's really the case any more.
So...with thanks to Lars / Xen Project for their input, I'm afraid I'm still in favor of this proposal, and still think we should drop the Xen criterion for F31. This wouldn't mean Xen is out of Fedora and we don't care about it any more, or anything like that; it would still be a part of Fedora and we still would like Xen to work on Fedora and Fedora to work on Xen, just like any other non-release-blocking package. It just means we would no longer block releases if it does not work.
Anyone have further thoughts on this? Xen folks, do you object to this really strenuously? If so I guess we could take this to a higher/wider level for more input. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org 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/test@lists.fedoraproject.org
On Mon, Jul 8, 2019 at 6:12 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
"The release must boot successfully as Xen DomU with releases
providing
a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen."
and change the 'milestone' for the test case -
https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
from Final to Optional.
Thoughts? Comments? Thanks!
I would prefer for it to remain as it is.
This is only practical if it's going to be tested, and tested
regularly
- not *only* on the final release candidate, right before we sign off
on the release. It needs to be tested regularly throughout the
release
cycle, on the composes that are "nominated for testing".
Would the proposal above work for you? I think it satisfies what you
are
looking for. We would also have someone who monitors these test results pro-actively.
In theory, yeah, but given the history here I'm somewhat sceptical. I'd also say we still haven't really got a convincing case for why we should continue to block the release (at least in theory) on Fedora working in Xen when we don't block on any other virt stack apart from our 'official' one, and we don't block on all sorts of other stuff we'd "like to have working" either. Regardless of the testing issues, I'd like to see that too if we're going to keep blocking on Xen...
So, this died here. As things stand: I proposed removing the Xen criterion, Lars opposed, we discussed the testing situation a bit, and I said overall I'm still inclined to remove the criterion because there's no clear justification for it for Fedora any more. Xen working (or rather, Fedora working on Xen) is just not a key requirement for Fedora at present, AFAICS.
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. Another consideration is that there was a time when KVM was still pretty new stuff and VirtualBox was not as popular as it is now, and Xen was still widely used for general hobbyist virtualization purposes; I don't believe that's really the case any more.
So...with thanks to Lars / Xen Project for their input, I'm afraid I'm still in favor of this proposal, and still think we should drop the Xen criterion for F31. This wouldn't mean Xen is out of Fedora and we don't care about it any more, or anything like that; it would still be a part of Fedora and we still would like Xen to work on Fedora and Fedora to work on Xen, just like any other non-release-blocking package. It just means we would no longer block releases if it does not work.
Agreed.
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.
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.
Peter
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.
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
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.
While trying hard to avoid a "haha he would say that" response, I do genuinely believe that's a reasonable canary and could cover most of the use cases that various users even outside EC2 would care about.
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.
I think we can define a set of instance types that would cover what it makes sense to test. Do we still care about actual PV guests or only HVM? I think it makes sense to test guests with Xen netback and blkback rather than only ENA and NVMe, but Fedora probably wants to test the latter two *anyway*.
Do we want to do this by making sure you have free credits to run the appropriate tests directly... or is it better all round for us to just do this on nightly builds for ourselves?
The latter brings me to a question that's been bugging me for a while — how in $DEITY's name *do* I launch the latest official Fedora AMI anyway? I can't find it through the normal GUI launch process and have to go to getfedora.org and click around for a while because I find the specific AMI ID for the that region, and then manually enter that to launch the instance. Can't we fix that so I can just select 'Fedora 30' with a single click? Whose heads do I have to bash together to make that work?
On Fri, Jul 12, 2019 at 5:50 AM David Woodhouse dwmw2@infradead.org wrote:
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
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.
While trying hard to avoid a "haha he would say that" response, I do genuinely believe that's a reasonable canary and could cover most of the use cases that various users even outside EC2 would care about.
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.
I think we can define a set of instance types that would cover what it makes sense to test. Do we still care about actual PV guests or only HVM? I think it makes sense to test guests with Xen netback and blkback rather than only ENA and NVMe, but Fedora probably wants to test the latter two *anyway*.
Do we want to do this by making sure you have free credits to run the appropriate tests directly... or is it better all round for us to just do this on nightly builds for ourselves?
The latter brings me to a question that's been bugging me for a while — how in $DEITY's name *do* I launch the latest official Fedora AMI anyway? I can't find it through the normal GUI launch process and have to go to getfedora.org and click around for a while because I find the specific AMI ID for the that region, and then manually enter that to launch the instance. Can't we fix that so I can just select 'Fedora 30' with a single click? Whose heads do I have to bash together to make that work?
So the easiest way to do this is by going to link [1] and select the cloud image "click to launch" it gives you a list of AWS regions and takes you direct to the AWS dialogs to run them.
On 12 Jul 2019, at 13:24, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Jul 12, 2019 at 5:50 AM David Woodhouse dwmw2@infradead.org wrote:
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.
I think we can define a set of instance types that would cover what it makes sense to test. Do we still care about actual PV guests or only HVM? I think it makes sense to test guests with Xen netback and blkback rather than only ENA and NVMe, but Fedora probably wants to test the latter two *anyway*.
Do we want to do this by making sure you have free credits to run the appropriate tests directly... or is it better all round for us to just do this on nightly builds for ourselves?
The latter brings me to a question that's been bugging me for a while — how in $DEITY's name *do* I launch the latest official Fedora AMI anyway? I can't find it through the normal GUI launch process and have to go to getfedora.org and click around for a while because I find the specific AMI ID for the that region, and then manually enter that to launch the instance. Can't we fix that so I can just select 'Fedora 30' with a single click? Whose heads do I have to bash together to make that work?
So the easiest way to do this is by going to link [1] and select the cloud image "click to launch" it gives you a list of AWS regions and takes you direct to the AWS dialogs to run them.
David, Peter, thanks for helping resolve this issue. It seems to me that testing against EC2 Xen instances should indeed cover what most users need Lars
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!
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd suggest c5.large (KVM, afaict) and t3.large (Xen).
My AWS experience is probably not representative (being mostly in the HPC space), but these seem like they'd hit the two use cases I'd expect to see for Fedora (compute and small servers). I would expect more people would use M rather than C for Fedora, but this gets us a KVM-based instance.
Happy to hear why I'm wrong. :-)
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis
On Mon, 2019-07-29 at 14:58 -0400, Ben Cotton wrote:
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd suggest c5.large (KVM, afaict) and t3.large (Xen).
My AWS experience is probably not representative (being mostly in the HPC space), but these seem like they'd hit the two use cases I'd expect to see for Fedora (compute and small servers). I would expect more people would use M rather than C for Fedora, but this gets us a KVM-based instance.
Happy to hear why I'm wrong. :-)
So, let's pick this up again.
Here's my latest proposal for the criteria wording:
"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 at least one KVM-based x86 instance type and at least one Xen-based x86 instance type."
I also propose we tweak the Cloud matrix:
https://fedoraproject.org/wiki/Template:Cloud_test_matrix
and replace the single "EC2" column with separate "EC2 (KVM)" and "EC2 (Xen)" columns. We would update the ec2 instructions on that page to include Matt Wilson's list of KVM and Xen instance types, and provide info on how to actually find the right AMIs (the page it currently links doesn't do that).
How does that sound to everyone?
On Fri, Nov 1, 2019 at 9:06 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2019-07-29 at 14:58 -0400, Ben Cotton wrote:
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd suggest c5.large (KVM, afaict) and t3.large (Xen).
My AWS experience is probably not representative (being mostly in the HPC space), but these seem like they'd hit the two use cases I'd expect to see for Fedora (compute and small servers). I would expect more people would use M rather than C for Fedora, but this gets us a KVM-based instance.
Happy to hear why I'm wrong. :-)
So, let's pick this up again.
Here's my latest proposal for the criteria wording:
"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 at least one KVM-based x86 instance type and at least one Xen-based x86 instance type."
I also propose we tweak the Cloud matrix:
https://fedoraproject.org/wiki/Template:Cloud_test_matrix
and replace the single "EC2" column with separate "EC2 (KVM)" and "EC2 (Xen)" columns. We would update the ec2 instructions on that page to include Matt Wilson's list of KVM and Xen instance types, and provide info on how to actually find the right AMIs (the page it currently links doesn't do that).
On aarch64 for EC2 they only support the "EC2 (KVM)" option so we probably need to note that.
How does that sound to everyone?
With the aarch64 amendment LGTM.
Peter
On 11/1/19 5:05 PM, Adam Williamson wrote:
On Mon, 2019-07-29 at 14:58 -0400, Ben Cotton wrote:
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd suggest c5.large (KVM, afaict) and t3.large (Xen).
My AWS experience is probably not representative (being mostly in the HPC space), but these seem like they'd hit the two use cases I'd expect to see for Fedora (compute and small servers). I would expect more people would use M rather than C for Fedora, but this gets us a KVM-based instance.
Happy to hear why I'm wrong. :-)
So, let's pick this up again.
Here's my latest proposal for the criteria wording:
"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 at least one KVM-based x86 instance type and at least one Xen-based x86 instance type."
I also propose we tweak the Cloud matrix:
https://fedoraproject.org/wiki/Template:Cloud_test_matrix
and replace the single "EC2" column with separate "EC2 (KVM)" and "EC2 (Xen)" columns. We would update the ec2 instructions on that page to include Matt Wilson's list of KVM and Xen instance types, and provide info on how to actually find the right AMIs (the page it currently links doesn't do that).
How does that sound to everyone?
Sounds good to me.
Dusty
On Fri, 2019-11-01 at 14:05 -0700, Adam Williamson wrote:
On Mon, 2019-07-29 at 14:58 -0400, Ben Cotton wrote:
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
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.
I'd suggest c5.large (KVM, afaict) and t3.large (Xen).
My AWS experience is probably not representative (being mostly in the HPC space), but these seem like they'd hit the two use cases I'd expect to see for Fedora (compute and small servers). I would expect more people would use M rather than C for Fedora, but this gets us a KVM-based instance.
Happy to hear why I'm wrong. :-)
So, let's pick this up again.
Here's my latest proposal for the criteria wording:
"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 at least one KVM-based x86 instance type and at least one Xen-based x86 instance type."
I also propose we tweak the Cloud matrix:
https://fedoraproject.org/wiki/Template:Cloud_test_matrix
and replace the single "EC2" column with separate "EC2 (KVM)" and "EC2 (Xen)" columns. We would update the ec2 instructions on that page to include Matt Wilson's list of KVM and Xen instance types, and provide info on how to actually find the right AMIs (the page it currently links doesn't do that).
How does that sound to everyone?
OK, as there were no objections to this, I've gone ahead and done it:
https://fedoraproject.org/w/index.php?title=Fedora_32_Final_Release_Criteria...
I also updated the validation matrix and instructions as discussed:
https://fedoraproject.org/w/index.php?title=Template:Cloud_test_matrix&d... https://fedoraproject.org/w/index.php?title=Template%3ACloud_Setup&type=...
and marked the Xen test as Optional on the installation matrix. Please let me know if anyone sees any issues here. Thanks!
-
Adam Williamson -
Adam Williamson -
Ben Cotton -
David Woodhouse -
Dusty Mabe -
Geoffrey Marr -
Kamil Paral -
Lars Kurth -
Peter Robinson