Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Elnikety, Eslam]

> On 1. Aug 2019, at 18:27, Ben Cotton  wrote:
> 
> On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam  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.
> 

Generally, different families represent different potential use cases, but of 
course I understand the need to identify a small, cheap set. Are we looking to 
cover net/blk-front, ENA, and NVMe? Maybe t2.nano and c5d.large?

> 
> Thanks,
> BC
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Ben Cotton]

On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam  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

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Elnikety, Eslam]

> On 29. Jul 2019, at 20:58, Ben Cotton  wrote:
> 
> On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson
>  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).

But t3 is not 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
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Ben Cotton]

On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson
 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

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

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


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

> 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


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Peter Robinson]

On Fri, Jul 12, 2019 at 5:50 AM David Woodhouse  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.

[1] https://alt.fedoraproject.org/cloud/

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Peter Robinson]

> 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

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[David Woodhouse]

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?




smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

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


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[David Woodhouse]

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.


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[marma...@invisiblethingslab.com]

On Thu, Jul 11, 2019 at 10:58:03AM -0700, Adam Williamson wrote:
> On Thu, 2019-07-11 at 09:57 -0500, Doug Goldstein wrote:
> > On 7/8/19 11:11 AM, Adam Williamson 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 I'll just point out this is false. Amazon very much uses Xen still 
> > and is investing in Xen still. In fact I'm writing this email from the 
> > XenSummit where Amazon is currently discussing their future development 
> > efforts for the Xen Project.
> 
> Sorry about that, it was just based on my best efforts at trying to
> figure it out; Amazon instance types don't all explicitly state exactly
> how they work.
> 
> Which EC2 instance types still use Xen?

I don't know what new instance types use Xen, but definitely there are
existing previous instance generations that are still running and not
going away anytime soon. From what I understand, they are still great
majority of EC2.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

On Thu, 2019-07-11 at 09:57 -0500, Doug Goldstein wrote:
> On 7/8/19 11:11 AM, Adam Williamson 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 I'll just point out this is false. Amazon very much uses Xen still 
> and is investing in Xen still. In fact I'm writing this email from the 
> XenSummit where Amazon is currently discussing their future development 
> efforts for the Xen Project.

Sorry about that, it was just based on my best efforts at trying to
figure it out; Amazon instance types don't all explicitly state exactly
how they work.

Which EC2 instance types still use Xen?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Doug Goldstein]

On 7/8/19 11:11 AM, Adam Williamson 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 I'll just point out this is false. Amazon very much uses Xen still 
and is investing in Xen still. In fact I'm writing this email from the 
XenSummit where Amazon is currently discussing their future development 
efforts for the Xen Project.


--

Doug



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Kamil Paral]

On Mon, Jul 8, 2019 at 6:12 PM Adam Williamson 
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.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Geoffrey Marr]

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 
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 -- t...@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/t...@lists.fedoraproject.org
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

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


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

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.pungi.compose.status.change
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/consumer.py

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.py
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 

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Kamil Paral]

On Mon, May 20, 2019 at 7:45 PM Lars Kurth  wrote:

> @Adam and Fedora Testing & QA:
> any views on my proposal?
> Regards
> Lars
>

Hi Lars,
thanks for your reply. Adam was on a long vacation and he's probably the
most qualified person to reply to you, sorry for not telling you sooner.
Adam is now back, so he should hopefully join the conversation shortly.

Cheers,
Kamil
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

@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 
> 
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> ) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 
> [B1] 
> https://bugzilla.redhat.com/show_bug.cgi?id=1703700 
> 
> The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
> While it is unpleasant, it doesn't break the release criterion, but
> probably has deterred people from testing. The second one [B1] is about
> Fedora _domU_, which breaks the release criterion.
> 
> Marek and Michael had a discussion about these and there was also
> a summary from Daniel.
> 
> == On [A1]/[A2] ==
> Lack of GRUB2 multiboot2/module2 commands in Fedora/RH which does not
> allow you load Xen as dom0 on EFI 

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[M A Young]

On Tue, 14 May 2019, Steven Haigh wrote:

> The final fix would be figuring out why pygrub currently boots the *second*
> entry in the resulting grub.cfg - unlike how F29 worked. This may be either a
> fix on the grub2-mkconfig or pygrub side - I'm not quite sure yet. This would
> likely restore functionality completely. At least until something else more
> suitable is done?

The answer to why is easy. pygrub just ignores "if" instructions and there 
is a
set default=1
line in an if clause from /etc/grub.d/08_fallback_counting so it 
defaults to the second entry as they are numbered from 0.

Michael Young

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Steven Haigh]

On Tue, May 14, 2019 at 11:50 PM, Lars Kurth  
wrote:

Apologies,
I mixed up some references
Lars


...

[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1703700


Bug B1 here was lodged by myself. There is also a post to xen-devel 
titled "pygrub not starting first menuentry in Fedora 30".


I just added a comment there which I shall paste below to include those 
not subscribed to that BZ:


Thinking about this further - and noticing it being referenced on 
xen-devel mailing list, I would like to suggest the following - which 
may have been overlooked right now...


If the grub %post scripting checked to see if it was installing / 
upgrading in a Xen DomU, it could set 'GRUB_ENABLE_BLSCFG=false' in 
/etc/default/grub automatically. This would fix both new installs and 
upgrades.


The final fix would be figuring out why pygrub currently boots the 
*second* entry in the resulting grub.cfg - unlike how F29 worked. This 
may be either a fix on the grub2-mkconfig or pygrub side - I'm not 
quite sure yet. This would likely restore functionality completely. At 
least until something else more suitable is done?




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

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 
> 
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> ) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 
> 
> [B1] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 
> 

[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 

> 
> The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
> While it is unpleasant, it doesn't break the release criterion, but
> probably has deterred people from testing. The second one [B1] is about
> Fedora _domU_, which breaks the release criterion.
> 
> Marek and Michael had a discussion about these and there was also
> a summary from Daniel.
> 
> == On [A1]/[A2] ==
> Lack of GRUB2 

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

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
 (and a recently filed duplicate @
  https://bugzilla.redhat.com/show_bug.cgi?id=1691559) caused by
  [A2])
[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1264103

The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
While it is unpleasant, it doesn't break the release criterion, but
probably has deterred people from testing. The second one [B1] is about
Fedora _domU_, which breaks the release criterion.

Marek and Michael had a discussion about these and there was also
a summary from Daniel.

== On [A1]/[A2] ==
Lack of GRUB2 multiboot2/module2 commands in Fedora/RH which does not
allow you load Xen as dom0 on EFI platforms with or without secure
boot. Here are some relevant snippets from the discussions:

"In general both modules were dropped due to CVE-2015-5281 (grub2:
modules built in on EFI builds that allow loading arbitrary code,
circumventing secure boot) [A3][A4]. Of course this makes sense
because we do not want to break UEFI secure boot. But this means
that you cannot boot Xen dom0 on UEFI platforms. The Multiboot2
protocol support is required to do that. Potentially you can
use xen.efi directly but 

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Daniel Kiper]

I have not heard that Peter moved to the Oracle ;-))), so, changing his
address back to RedHat one. And dropping Fedora testing mailing list
address because I do not have permissions to send to it...

On Mon, Apr 29, 2019 at 10:51:47AM +0200, Daniel Kiper wrote:
> Sorry for top posting...
>
> FYI, I am on vacation right now. I will be back next week. So, if it is
> not urgent I will explain all the stuff and update relevant bug at the
> beginning of next week. Sorry for delay.
>
> Daniel
>
> On Sun, Apr 28, 2019 at 12:44:37PM +1000, Steven Haigh wrote:
> > (and sending to the list this time due to Geary being rather featureless
> > mail client)
> >
> > As one of those being caught by regressions upgrading F29 to F30 under Xen
> > DomU's, I think this is a bad idea.
> >
> > It shows that it wasn't tested, because it doesn't work. To me, this exposes
> > weaknesses in the testing and the solution shouldn't be "The check fails,
> > remove the check".
> >
> > On Sat, Apr 27, 2019 at 4:18 AM, Konrad Rzeszutek Wilk
> >  wrote:
> > > On Fri, Apr 26, 2019 at 10:22:13PM +0530, Sumantro Mukherjee wrote:
> > > >  Yup +1 from my side too. Xen is hardly tested since a lot of time.
> > >
> > > Hi!
> > >
> > > And that is thanks to one of the GRUB2 bugs that needs some love
> > > from Peter Jones.
> > >
> > > As without that bug being fixed - it is very difficult to test it - as
> > > you can't even load Xen!
> > >
> > > I've asked the upstream GRUB maintainer to sheed some light on the
> > > confusion about multiboot2 + SecureBoot - hopefully that will resolve
> > > the question.
> > >
> > > My vote is to have it remain as is.
> > >
> > > Thank you.
> > > >
> > > >  On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr 
> > > > wrote:
> > > >
> > > >  > Since F24, I haven't seen or heard of anyone who uses Xen over KVM
> > > >  > anywhere other than this thread... I'm +1 for making this test an
> > > >  > "Optional" one.
> > > >  >
> > > >  > Geoff Marr
> > > >  > IRC: coremodule
> > > >  >
> > > >  >
> > > >  > On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson <
> > > >  > adamw...@fedoraproject.org> wrote:
> > > >  >
> > > >  >> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> > > >  >> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > >  >> > > > > 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".
> > > >  >> > >
> > > >  >> > > Right, which is why I am happy that you have pointed me to
> > > > the right
> > > >  >> > > place so I can be up-to-date.
> > > >  >> >
> > > >  >> > Great, thanks. So let's leave it as it is for now, but we'll
> > > > keep an
> > > >  >> > eye on this during F27 cycle. If we get to, say, Beta and
> > > > there are no
> > > >  >> > results for the test, that's gonna be a problem. Thanks!
> > > >  >>
> > > >  >> So, for Fedora 30, this was not tested throughout the whole
> > > > cycle. I
> > > >  >> think we can consider the proposal to remove the criterion active
> > > >  >> again.
> > > >  >> --
> > > >  >> Adam Williamson
> > > >  >> Fedora QA Community Monkey
> > > >  >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT
> > > > happyassassin . net
> > > >  >> http://www.happyassassin.net
> > > >  >> ___
> > > >  >> test mailing list -- t...@lists.fedoraproject.org
> > > >  >> To unsubscribe send an email to
> > > > test-le...@lists.fedoraproject.org
> > > >  >> Fedora Code of Conduct:
> > > > https://getfedora.org/code-of-conduct.html
> > > >  >> List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > >  >> List Archives:
> > > >  >> 
> > > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> > > >  >>
> > > >  > ___
> > > >  > test mailing list -- t...@lists.fedoraproject.org
> > > >  > To unsubscribe send an email to test-le...@lists.fedoraproject.org
> > > >  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > >  > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > >  > List Archives:
> > > >  > 
> > > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> > > >  >
> > > >
> > > >
> > > >  --
> > > >  //sumantro
> > > >  Fedora QE
> > > >  TRIED AND PERSONALLY TESTED, ERGO TRUSTED
> > > > 
> > >
> > > ___
> > > Xen-devel mailing list
> > > Xen-devel@lists.xenproject.org
> > > https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Daniel Kiper]

Sorry for top posting...

FYI, I am on vacation right now. I will be back next week. So, if it is
not urgent I will explain all the stuff and update relevant bug at the
beginning of next week. Sorry for delay.

Daniel

On Sun, Apr 28, 2019 at 12:44:37PM +1000, Steven Haigh wrote:
> (and sending to the list this time due to Geary being rather featureless
> mail client)
>
> As one of those being caught by regressions upgrading F29 to F30 under Xen
> DomU's, I think this is a bad idea.
>
> It shows that it wasn't tested, because it doesn't work. To me, this exposes
> weaknesses in the testing and the solution shouldn't be "The check fails,
> remove the check".
>
> On Sat, Apr 27, 2019 at 4:18 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Fri, Apr 26, 2019 at 10:22:13PM +0530, Sumantro Mukherjee wrote:
> > >  Yup +1 from my side too. Xen is hardly tested since a lot of time.
> >
> > Hi!
> >
> > And that is thanks to one of the GRUB2 bugs that needs some love
> > from Peter Jones.
> >
> > As without that bug being fixed - it is very difficult to test it - as
> > you can't even load Xen!
> >
> > I've asked the upstream GRUB maintainer to sheed some light on the
> > confusion about multiboot2 + SecureBoot - hopefully that will resolve
> > the question.
> >
> > My vote is to have it remain as is.
> >
> > Thank you.
> > >
> > >  On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr 
> > > wrote:
> > >
> > >  > Since F24, I haven't seen or heard of anyone who uses Xen over KVM
> > >  > anywhere other than this thread... I'm +1 for making this test an
> > >  > "Optional" one.
> > >  >
> > >  > Geoff Marr
> > >  > IRC: coremodule
> > >  >
> > >  >
> > >  > On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson <
> > >  > adamw...@fedoraproject.org> wrote:
> > >  >
> > >  >> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> > >  >> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> > >  >> > > > > 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".
> > >  >> > >
> > >  >> > > Right, which is why I am happy that you have pointed me to
> > > the right
> > >  >> > > place so I can be up-to-date.
> > >  >> >
> > >  >> > Great, thanks. So let's leave it as it is for now, but we'll
> > > keep an
> > >  >> > eye on this during F27 cycle. If we get to, say, Beta and
> > > there are no
> > >  >> > results for the test, that's gonna be a problem. Thanks!
> > >  >>
> > >  >> So, for Fedora 30, this was not tested throughout the whole
> > > cycle. I
> > >  >> think we can consider the proposal to remove the criterion active
> > >  >> again.
> > >  >> --
> > >  >> Adam Williamson
> > >  >> Fedora QA Community Monkey
> > >  >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT
> > > happyassassin . net
> > >  >> http://www.happyassassin.net
> > >  >> ___
> > >  >> test mailing list -- t...@lists.fedoraproject.org
> > >  >> To unsubscribe send an email to
> > > test-le...@lists.fedoraproject.org
> > >  >> Fedora Code of Conduct:
> > > https://getfedora.org/code-of-conduct.html
> > >  >> List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >  >> List Archives:
> > >  >> 
> > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> > >  >>
> > >  > ___
> > >  > test mailing list -- t...@lists.fedoraproject.org
> > >  > To unsubscribe send an email to test-le...@lists.fedoraproject.org
> > >  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > >  > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >  > List Archives:
> > >  > 
> > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> > >  >
> > >
> > >
> > >  --
> > >  //sumantro
> > >  Fedora QE
> > >  TRIED AND PERSONALLY TESTED, ERGO TRUSTED
> > > 
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xenproject.org
> > https://lists.xenproject.org/mailman/listinfo/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Steven Haigh]

(and sending to the list this time due to Geary being rather 
featureless mail client)


As one of those being caught by regressions upgrading F29 to F30 under 
Xen DomU's, I think this is a bad idea.


It shows that it wasn't tested, because it doesn't work. To me, this 
exposes weaknesses in the testing and the solution shouldn't be "The 
check fails, remove the check".


On Sat, Apr 27, 2019 at 4:18 AM, Konrad Rzeszutek Wilk 
 wrote:

On Fri, Apr 26, 2019 at 10:22:13PM +0530, Sumantro Mukherjee wrote:

 Yup +1 from my side too. Xen is hardly tested since a lot of time.


Hi!

And that is thanks to one of the GRUB2 bugs that needs some love
from Peter Jones.

As without that bug being fixed - it is very difficult to test it - 
as you can't even load Xen!


I've asked the upstream GRUB maintainer to sheed some light on the
confusion about multiboot2 + SecureBoot - hopefully that will resolve
the question.

My vote is to have it remain as is.

Thank you.


 On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr  
wrote:


 > Since F24, I haven't seen or heard of anyone who uses Xen over KVM
 > anywhere other than this thread... I'm +1 for making this test an
 > "Optional" one.
 >
 > Geoff Marr
 > IRC: coremodule
 >
 >
 > On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson <
 > adamw...@fedoraproject.org> wrote:
 >
 >> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
 >> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
 >> > > > > 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".
 >> > >
 >> > > Right, which is why I am happy that you have pointed me to 
the right

 >> > > place so I can be up-to-date.
 >> >
 >> > Great, thanks. So let's leave it as it is for now, but we'll 
keep an
 >> > eye on this during F27 cycle. If we get to, say, Beta and 
there are no

 >> > results for the test, that's gonna be a problem. Thanks!
 >>
 >> So, for Fedora 30, this was not tested throughout the whole 
cycle. I

 >> think we can consider the proposal to remove the criterion active
 >> again.
 >> --
 >> Adam Williamson
 >> Fedora QA Community Monkey
 >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT 
happyassassin . net

 >> http://www.happyassassin.net
 >> ___
 >> test mailing list -- t...@lists.fedoraproject.org
 >> To unsubscribe send an email to 
test-le...@lists.fedoraproject.org
 >> Fedora Code of Conduct: 
https://getfedora.org/code-of-conduct.html
 >> List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines

 >> List Archives:
 >> 
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org

 >>
 > ___
 > test mailing list -- t...@lists.fedoraproject.org
 > To unsubscribe send an email to test-le...@lists.fedoraproject.org
 > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
 > List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines

 > List Archives:
 > 
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org

 >


 --
 //sumantro
 Fedora QE
 TRIED AND PERSONALLY TESTED, ERGO TRUSTED 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Geoffrey Marr]

Since F24, I haven't seen or heard of anyone who uses Xen over KVM anywhere
other than this thread... I'm +1 for making this test an "Optional" one.

Geoff Marr
IRC: coremodule


On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson 
wrote:

> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > 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".
> > >
> > > Right, which is why I am happy that you have pointed me to the right
> > > place so I can be up-to-date.
> >
> > Great, thanks. So let's leave it as it is for now, but we'll keep an
> > eye on this during F27 cycle. If we get to, say, Beta and there are no
> > results for the test, that's gonna be a problem. Thanks!
>
> So, for Fedora 30, this was not tested throughout the whole cycle. I
> think we can consider the proposal to remove the criterion active
> again.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> test mailing list -- t...@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Sumantro Mukherjee]

Yup +1 from my side too. Xen is hardly tested since a lot of time.

On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr  wrote:

> Since F24, I haven't seen or heard of anyone who uses Xen over KVM
> anywhere other than this thread... I'm +1 for making this test an
> "Optional" one.
>
> Geoff Marr
> IRC: coremodule
>
>
> On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
>> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
>> > > > > 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".
>> > >
>> > > Right, which is why I am happy that you have pointed me to the right
>> > > place so I can be up-to-date.
>> >
>> > Great, thanks. So let's leave it as it is for now, but we'll keep an
>> > eye on this during F27 cycle. If we get to, say, Beta and there are no
>> > results for the test, that's gonna be a problem. Thanks!
>>
>> So, for Fedora 30, this was not tested throughout the whole cycle. I
>> think we can consider the proposal to remove the criterion active
>> again.
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>> http://www.happyassassin.net
>> ___
>> test mailing list -- t...@lists.fedoraproject.org
>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>>
> ___
> test mailing list -- t...@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>


-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Konrad Rzeszutek Wilk]

On Fri, Apr 26, 2019 at 10:22:13PM +0530, Sumantro Mukherjee wrote:
> Yup +1 from my side too. Xen is hardly tested since a lot of time.

Hi!

And that is thanks to one of the GRUB2 bugs that needs some love
from Peter Jones.

As without that bug being fixed - it is very difficult to test it - as you 
can't even load Xen!

I've asked the upstream GRUB maintainer to sheed some light on the 
confusion about multiboot2 + SecureBoot - hopefully that will resolve
the question.

My vote is to have it remain as is.

Thank you.
> 
> On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr  wrote:
> 
> > Since F24, I haven't seen or heard of anyone who uses Xen over KVM
> > anywhere other than this thread... I'm +1 for making this test an
> > "Optional" one.
> >
> > Geoff Marr
> > IRC: coremodule
> >
> >
> > On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson <
> > adamw...@fedoraproject.org> wrote:
> >
> >> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> >> > On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> >> > > > > 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".
> >> > >
> >> > > Right, which is why I am happy that you have pointed me to the right
> >> > > place so I can be up-to-date.
> >> >
> >> > Great, thanks. So let's leave it as it is for now, but we'll keep an
> >> > eye on this during F27 cycle. If we get to, say, Beta and there are no
> >> > results for the test, that's gonna be a problem. Thanks!
> >>
> >> So, for Fedora 30, this was not tested throughout the whole cycle. I
> >> think we can consider the proposal to remove the criterion active
> >> again.
> >> --
> >> Adam Williamson
> >> Fedora QA Community Monkey
> >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> >> http://www.happyassassin.net
> >> ___
> >> test mailing list -- t...@lists.fedoraproject.org
> >> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> >>
> > ___
> > test mailing list -- t...@lists.fedoraproject.org
> > To unsubscribe send an email to test-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
> >
> 
> 
> -- 
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Adam Williamson]

On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > > 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".
> > 
> > Right, which is why I am happy that you have pointed me to the right
> > place so I can be up-to-date.
> 
> Great, thanks. So let's leave it as it is for now, but we'll keep an
> eye on this during F27 cycle. If we get to, say, Beta and there are no
> results for the test, that's gonna be a problem. Thanks!

So, for Fedora 30, this was not tested throughout the whole cycle. I
think we can consider the proposal to remove the criterion active
again.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel