On Thu, 2019-12-19 at 13:10 +0100, Adam Samalik wrote:
> On Fri, Dec 13, 2019 at 8:20 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> wrote:
>
> > On Fri, 2019-12-13 at 09:19 -0800, Kevin Fenzi wrote:
> > > It would be great if they could include the size +/- of all the images.
> > > Of course the most important ones would be boot.iso, workstation and
> > > server, but labs and spins could be very helpfull as well.
> >
> > This sort of thing is what fedfind can help with. As an example of
> > where you'd start:
> >
> > #!/bin/python3
> >
> > import fedfind.release
> > import fedfind.helpers
> >
> > rel = fedfind.release.get_release(cid="Fedora-Rawhide-20191213.n.0")
> > #rel = fedfind.release.get_release(1)
> > for img in rel.all_images:
> > imgid = fedfind.helpers.identify_image(img, out='string')
> > if img['disc_number'] > 1:
> > imgid += " disc {0}".format(img['disc_number'])
> > size = img.get('size')
> > if not size:
> > # this is something I should make fedfind handle...
> > # I swear it used to!
> > size = fedfind.helpers.get_size(img['direct_url'])
> > print("{0}: {1}".format(imgid, size))
> >
> > hopefully it's pretty simple to see where to go from there. :) You can
> > try it with either of the 'rel' lines and it'll work...so you can
> > compare the image sizes from Fedora Core 1 with those from today's
> > Rawhide nightly, though they only have one image entirely in common
> > (Everything-boot-iso).
> >
> > You can see I had to add a couple of bits to smoothly work with the
> > info for very old composes...I'll maybe tweak that a bit in fedfind
> > itself today, that code doesn't actually get *used* a lot so when I do
> > want to do something like this I usually find some issues that have
> > crept in.
> >
> > This should work for any Pungi 4 compose that hasn't been garbage
> > collected yet, and also for all stable releases and old candidate
> > composes.
> >
> > It...*could* also work for non-candidate (i.e. nightly) Pungi 4
> > composes that have been garbage collected by retrieving the info from
> > PDC, but this thread has made me realize that's a path that I've sort
> > of shut off with some design choices and I need to think about how to
> > open it up again.
> >
>
> That is really cool. And I'm aware of the compose report that goes to devel.
>
> What I'm looking for is sizes of (and other info about) some specific use
> cases,
> that we don't actually produce as artifacts. Like the httpd web server
> installed
> on top of an image we produce, etc. They represent something that people
> often install themselves as opposed us producing an image.
Right, I was replying to Kevin's suggestion, which *is* about the sizes
of the images. I guess we can say that since fedfind can do the above,
either the Feedback Pipeline wouldn't need to implement Kevin's
suggestion, or if it wants to be the frontend for it, fedfind could
potentially help on the back end.
> My goal is to detect changes that affect those use cases. It's conceptually
> similar to some parts of the compose report, just looking at a different
> thing.
>
> There is also one technical difference: Because we don't produce the use
> cases
> as artifacts (we produce the very useful bits people can use to build
> those),
> the service also needs to build them so it actually has something to look
> at.
>
> So I prototyped the service to validate its usefulness. And I'd be happy to
> throw away most of the code if something similar exists already — which was
> the reason it's not really optimized.
>
> Now I'm thinking if I could somehow use fedfind or the CI infrastructure
> for that...
Yeah, going back to the overall idea of the Feedback Pipeline, I just
wanted to make sure you were aware of this so we can avoid any
duplication if possible. If it turns out that fedfind/check-compose
don't help, hey, never mind. I'm happy to look at extending it in ways
that make sense if it could be useful, though doing some things may be
architecturally difficult and not worth the effort - it really depends
a lot on the details. I'm happy to kick those details around with you
any time, IRC or email :)
One thing I am going to do if I can find time is somehow set things up
so the data files we collect from openQA tests that check-compose uses
as its inputs don't get garbage collected after a while. We *should*
have interesting data on service loadouts and so on going back to the
date when I first started having openQA collect this data, but because
the files get garbage collected, we don't :( I will try and fix that
for sure, so if nothing else, systems like this can use that historical
data going forward.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
