Re: [Xen-devel] Criteria / validation proposal: drop Xen
> On 12 Jul 2019, at 13:24, Peter Robinson wrote: > > On Fri, Jul 12, 2019 at 5:50 AM David Woodhouse 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. > > [1] https://alt.fedoraproject.org/cloud/ 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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: [Xen-devel] Criteria / validation proposal: drop Xen
@Adam and Fedora Testing & QA: any views on my proposal? Regards Lars > On 13 May 2019, at 16:29, 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. > >> On 6 Jul 2017, at 13:45, Adam Williamson wrote: >> >> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote: >>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote: >>>> Hi, folks! A while ago, Xen virtualization functionality was added to >>>> the criteria and the validation test case set, on the understanding >>>> that Oracle would provide testing for it (and help fix bugs as they >>>> arose). >>>> >>>> For the last couple of releases we really have not had any such testing >>> >>> We had been doing the testing, it just that we (or rather me and >>> Dariof) seem to get a wind of this at the last minute. Not sure exactly >>> how to fix that thought. >> >> 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? > >>>> 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@ > >>>> "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. > > Then, there are the specific grub issues that need resolving > [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 > <https://bugzilla.redhat.com/show_bug.cgi?id=1486002> > (and a recently filed duplicate @ > https://bugzilla.redhat.com/show_bug.cgi?id=1691559 > <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by > [A2]) > [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 > <https://bugzilla.redhat.com/s
Re: [Xen-devel] Criteria / validation proposal: drop Xen
Apologies, I mixed up some references Lars > On 13 May 2019, at 16:29, 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. > >> On 6 Jul 2017, at 13:45, Adam Williamson wrote: >> >> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote: >>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote: >>>> Hi, folks! A while ago, Xen virtualization functionality was added to >>>> the criteria and the validation test case set, on the understanding >>>> that Oracle would provide testing for it (and help fix bugs as they >>>> arose). >>>> >>>> For the last couple of releases we really have not had any such testing >>> >>> We had been doing the testing, it just that we (or rather me and >>> Dariof) seem to get a wind of this at the last minute. Not sure exactly >>> how to fix that thought. >> >> 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? > >>>> 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@ > >>>> "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. > > Then, there are the specific grub issues that need resolving > [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 > <https://bugzilla.redhat.com/show_bug.cgi?id=1486002> > (and a recently filed duplicate @ > https://bugzilla.redhat.com/show_bug.cgi?id=1691559 > <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by > [A2]) > [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 > <https://bugzilla.redhat.com/show_bug.cgi?id=1703700> >
