qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEM


From: Ani Sinha
Subject: Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEMU bios tables using biosbits
Date: Wed, 28 Sep 2022 08:38:54 +0530

On Wed, Sep 28, 2022 at 2:48 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Sep 27, 2022 at 09:33:27AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Sep 27, 2022 at 01:43:15PM +0530, Ani Sinha wrote:
> > > On Sun, Sep 18, 2022 at 1:58 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Fri, Sep 16, 2022 at 09:30:42PM +0530, Ani Sinha wrote:
> > > > > On Thu, Jul 28, 2022 at 12:08 AM Ani Sinha <ani@anisinha.ca> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 25 Jul 2022, Ani Sinha wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, 16 Jul 2022, Michael S. Tsirkin wrote:
> > > > > > >
> > > > > > > > On Sat, Jul 16, 2022 at 12:06:00PM +0530, Ani Sinha wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jul 15, 2022 at 11:20 Michael S. Tsirkin 
> > > > > > > > > <mst@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > >     On Fri, Jul 15, 2022 at 09:47:27AM +0530, Ani Sinha wrote:
> > > > > > > > >     > > Instead of all this mess, can't we just spawn e.g. 
> > > > > > > > > "git clone --depth
> > > > > > > > >     1"?
> > > > > > > > >     > > And if the directory exists I would fetch and 
> > > > > > > > > checkout.
> > > > > > > > >     >
> > > > > > > > >     > There are two reasons I can think of why I do not like 
> > > > > > > > > this idea:
> > > > > > > > >     >
> > > > > > > > >     > (a) a git clone of a whole directory would download all 
> > > > > > > > > versions of the
> > > > > > > > >     > binary whereas we want only a specific version.
> > > > > > > > >
> > > > > > > > >     You mention shallow clone yourself, and I used --depth 1 
> > > > > > > > > above.
> > > > > > > > >
> > > > > > > > >     > Downloading a single file
> > > > > > > > >     > by shallow cloning or creating a git archive is 
> > > > > > > > > overkill IMHO when a wget
> > > > > > > > >     > style retrieval works just fine.
> > > > > > > > >
> > > > > > > > >     However, it does not provide for versioning, tagging etc 
> > > > > > > > > so you have
> > > > > > > > >     to implement your own schema.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hmm I’m not sure if we need all that. Bits has its own 
> > > > > > > > > versioning mechanism and
> > > > > > > > > I think all we need to do is maintain the same versioning 
> > > > > > > > > logic and maintain
> > > > > > > > > binaries of different  versions. Do we really need the power 
> > > > > > > > > of git/version
> > > > > > > > > control here? Dunno.
> > > > > > > >
> > > > > > > > Well we need some schema. Given we are not using official bits 
> > > > > > > > releases
> > > > > > > > I don't think we can reuse theirs.
> > > > > > >
> > > > > > > OK fine. Lets figuire out how to push bits somewhere in 
> > > > > > > git.qemu.org and
> > > > > > > the binaries in some other repo first. Everything else hinges on 
> > > > > > > that. We
> > > > > > > can fix the rest of the bits later incrementally.
> > > > > >
> > > > > > DanPB, any thoughts on putting bits on git.qemu.org or where and 
> > > > > > how to
> > > > > > keep the binaries?
> > > > >
> > > > > Can we please conclude on this?
> > > > > Peter, can you please fork the repo? I have tried many times to reach
> > > > > you on IRC but failed.
> > > >
> > > > Probably because of travel around KVM forum.
> > > >
> > > > I think given our CI is under pressure again due to gitlab free tier
> > > > limits, tying binaries to CI isn't a great idea at this stage.
> > > > Can Ani just upload binaies to qemu.org for now?
> > >
> > > I agree with Michael here. Having a full ci/cd job for this is
> > > overkill IMHO. We should create a repo just for the binaries, have a
> > > README there to explain how we generate them and check in new versions
> > > as and when needed (it won't be frequent).
> > > How about biosbits-bin repo?
> >
> > If QEMU is hosting binaries, where any part contains GPL code, then we
> > need to be providing the full and corresponding source and the build
> > scripts needed to re-create the binary. Once we have such scripts it
> > should be trivial to trigger that from a CI job. If it isn't then
> > we're doing something wrong.  The CI quota is not an issue, because
> > this is not a job that we need to run continuously. It can be triggered
> > manually as & when we decide we need to refresh the binary, so would
> > be a small one-off CI quota hit.
> >
> > Also note that gitlab is intending to start enforcing storage quota
> > on projects in the not too distant future. This makes it unappealing
> > to store binaries in git repos, unless we genuinely need the ability
> > to access historical versions of the binary. I don't believe we need
> > that for biosbits.
> >
> > The binary can be published as a CI artifact and accessed directly
> > from the latest artifact download link. This ensures we only consume
> > quota for the most recently published binary artifact. So I don't see
> > a compelling reason to upload binaries into git.
> >
> > With regards,
> > Daniel
>
> I don't really care where we upload them but only having the
> latest version is just going to break anything expecting
> the old binary.

In fairness, I am not entirely certain if there is a tight coupling
between the qemu tests and the bits binaries. I have written the test
framework in a way such that test modifications and new tests can be
pushed into the bits binaries and the iso gets regenerated with the
new tests from QEMU itself before running the tests. Only when we need
bits bugfixes or say upgrade to new acpica that we would need to
regenerate the bits binaries.

>
>
>
> > --
> > |: 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 
> > :|
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]