Re: What has the PDC ever done for us?

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

 



On Thu, 2022-03-17 at 12:34 +0100, Miro Hrončok wrote:
> 
> Where is the sanitation, medicine, education, wine, public order, irrigation, 
> roads, a fresh water system, and public health that the PDC have done for us?
> 
> 
> Serious question: Why do we need PDC? What actual problems does it solve?

It stores the metadata of all composes that have been run, ever. (Well,
when there isn't a bug in the sync, anyway). This is useful in several
ways:

1. It's the best way I know of to figure out what the "previous"
compose was. fedfind implements two ways of doing this, one based on
PDC, one not. Here they are. You judge which is less awful:

https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1293 (PDC)
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1380 (not PDC)

2. It's useful if you want to look at the history of, e.g., what
packages were in what composes, or what size images were. The actual
nightly composes are garbage-collected after two weeks, so unless you
have your own stash of their metadata, you cannot find this information
for nightly composes that are more than two weeks old anywhere but PDC.
With the PDC metadata you can chart image sizes or package changes
between nightly composes from five years ago, if you want. Without the
PDC metadata you can only do it for composes we still have around -
final releases, maybe Beta releases - and it's painful even for those
because we don't actually keep the metadata for them in the live trees,
you have to figure out what you want to know from HTTP requests (ugh).

3. It's actually very useful for handling exactly that case of how we
screw up composes when we release them. When we take a compose and
release it as a Beta or Final release, we throw some things away and
move other things around, and because of that, we don't publish the
metadata for it in the repos because it's not exactly correct any more.
But that, well, sucks. If you ask fedfind for the metadata of a final
or Beta release, what it does is find the metadata for the source
compose of that release in PDC, then amend it in a way that reflects
how releng hacked it up, and present you with modified, accurate
metadata:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1876
it's the path there where we *do* find `origmd` (the path where we
*don't* is for handling releases that were done before Pungi 4 / PDC,
and it provides much less complete, synthesized metadata). Once the
original, unmodified composes have been garbage-collected from
https://kojipkgs.fedoraproject.org/compose/ and
https://dl.fedoraproject.org/pub/alt/stage/ , PDC is the *only* place
you can get this metadata.

4. It's the only way I know of for finding out what the compose ID of a
candidate compose was if all you have is its label. For example, for
the Fedora 36 Beta candidate compose, its compose ID was "Fedora-36-
20220311.0", and its label was "Beta-1.1"; if you want to look up "what
compose was 36 Beta-1.1?" the only solid way to do it is in PDC. This
is kind of esoteric, I guess, but for boring reasons I won't go into
it's something I actually need in the release validation process
automation.

5. It's the most convenient way to look up "what version of packages X,
Y and Z were in compose foo?", which fedfind does here:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1320
the only alternatives I know of are to parse HTTP requests, which is
awful and doesn't get you epochs, or grab the entire `rpms.json`
metadata for the compose and parse that, which works but it's nearly
200MB, which is a lot to download just to query five packages. And you
can only do those two if the compose hasn't been garbage-collected (see
point 2). We use this and "previous" compose discovery (point 1) in the
release validation event creation code - we query the versions of
several key packages (e.g. anaconda and gnome-shell) in the current and
'previous' composes, and if any of them has changed, we are more likely
to create a new event than if none of them has changed.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux