From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Cleber Rosa <crosa@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Willian Rampazzo" <wrampazz@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [PATCH-for-5.2? 1/1] Acceptance tests: bump Fedora to 32
Date: Thu, 3 Dec 2020 17:02:33 +0000 [thread overview]
Message-ID: <20201203170233.GK2952498@redhat.com> (raw)
In-Reply-To: <20201203165033.GB2787993@localhost.localdomain>
On Thu, Dec 03, 2020 at 11:50:33AM -0500, Cleber Rosa wrote:
> On Thu, Dec 03, 2020 at 10:37:01AM +0100, Philippe Mathieu-Daudé wrote:
> > On 12/2/20 10:57 PM, Cleber Rosa wrote:
> > > Currently in use Fedora 31 has been moved out of the standard download
> > > locations that are supported by the functionality provided by
> > > avocado.utils.vmimage. So right now, the boot_linux.py tests will get
> > > canceled by not being able to find those specific images.
> > >
> > > Ideally, this would be bumped to version 33. But, I've found issues
> > > with the aarch64 images, with various systemd services failing to
> > > start. So to keep all archs consistent, I've settled on 32.
> > >
> > > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > > ---
> > > tests/acceptance/boot_linux.py | 12 ++++++------
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
> > > index 1da4a53d6a..0824de008e 100644
> > > --- a/tests/acceptance/boot_linux.py
> > > +++ b/tests/acceptance/boot_linux.py
> > > @@ -42,13 +42,13 @@ class BootLinuxBase(Test):
> > > vmimage.QEMU_IMG = qemu_img
> > >
> > > self.log.info('Downloading/preparing boot image')
> > > - # Fedora 31 only provides ppc64le images
> > > + # Fedora 32 only provides ppc64le images
> > > image_arch = self.arch
> > > if image_arch == 'ppc64':
> > > image_arch = 'ppc64le'
> > > try:
> > > boot = vmimage.get(
> > > - 'fedora', arch=image_arch, version='31',
> > > + 'fedora', arch=image_arch, version='32',
> >
> > I already expressed my view on this (latest QEMU should be
> > able to use at least f31 - which was tested - and eventually
> > f33 - which is coverage extension). I'm not going to vouch
> > this change. If other maintainers are happy with it, I don't
> > mind this gets merged.
> >
> > BTW I don't see why this is urgent for 5.2.
> >
> > Phil.
> >
>
> Hi Phil,
>
> Are you implying that, in your opinion, QEMU (say 5.2) should somehow
> provide compatibility with Fedora 31 because it was used during the
> entire cycle? I sympathize with that, but, QEMU is not really
> advertising compatibility support with specific Linux Distros, is it?
>
> And, assuming that the issues I found on the Fedora 33 aarch64 image
> can not be worked around, would you suggest not moving to 32? I mean,
> I don't see a reason why QEMU shouldn't be able to use at least Fedora
> 32, which is a currently *active* version (different from 31).
I think the problem with the Fedora acceptance is that we'll be constantly
chasing a moving target. Every URL we pick will go away 6-12 months later.
IOW, while the acceptance test pass today, in 6 months time they'll be
failing. IOW, switching to F32 doesn't solve the root cause, it just
pushs the problem down the road for 6 months until F32 is EOL and hits
the same URL change problem.
One way to avoid this is to *not* actually test a current Fedora.
Instead intentionally point at an EOL Fedora release whose URL has
already moved to the archive site which is long term stable.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-12-03 17:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 21:57 [PATCH-for-5.2? 0/1] Acceptance tests: bump Fedora to 32 Cleber Rosa
2020-12-02 21:57 ` [PATCH-for-5.2? 1/1] " Cleber Rosa
2020-12-03 9:37 ` Philippe Mathieu-Daudé
2020-12-03 16:50 ` Cleber Rosa
2020-12-03 17:02 ` Daniel P. Berrangé [this message]
2020-12-03 17:29 ` Cleber Rosa
2020-12-03 17:36 ` Daniel P. Berrangé
2020-12-03 18:13 ` Willian Rampazzo
2020-12-04 14:08 ` Philippe Mathieu-Daudé
2020-12-04 14:19 ` Daniel P. Berrangé
2020-12-03 10:09 ` [PATCH-for-5.2? 0/1] " Peter Maydell
2020-12-03 16:39 ` Cleber Rosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201203170233.GK2952498@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=wrampazz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.