#11926 scripts/critpath.py: support adding CoreOS-defined gated RPMs
Merged 3 months ago by kevin. Opened 3 months ago by jlebon.
jlebon/releng pr/critpath-with-coreos  into  main

file modified
+34
@@ -15,6 +15,7 @@ 

  import argparse

  from collections import defaultdict

  import json

+ import yaml

  import shutil

  from tempfile import mkdtemp

  from urllib.request import urlopen
@@ -56,6 +57,13 @@ 

  BODHI_RELEASEURL = "https://bodhi.fedoraproject.org/releases/?rows_per_page=500"

  FEDORA_BASEURL = "http://dl.fedoraproject.org/pub/fedora/linux/"

  FEDORA_ALTERNATEURL = "http://dl.fedoraproject.org/pub/fedora-secondary/"

+ # note this name is synthetic; it does not correspond to an actual comps group

+ COREOS_CRITPATH_GROUP = "critical-path-coreos"

+ COREOS_CONFIG_URL = "https://raw.githubusercontent.com/coreos/coreos-ci/main/bodhi-testing.yaml"

+ 

+ # used as a cache by get_coreos_gating_data

+ COREOS_GATED_SRPMS = None

+ 

  # used as a cache by get_bodhi_releases

  BODHIRELEASES = {}

  
@@ -81,6 +89,14 @@ 

      return BODHIRELEASES

  

  

+ def get_coreos_gated_srpms():

+     global COREOS_GATED_SRPMS

+     if COREOS_GATED_SRPMS is None:

+         config_data = yaml.safe_load(urlopen(COREOS_CONFIG_URL).read().decode("utf8"))

+         COREOS_GATED_SRPMS = config_data.get("gated-srpms", [])

+     return COREOS_GATED_SRPMS

+ 

+ 

  def get_paths(release, forcebranched=False):

      """This does a certain amount of fudging so we can refer to

      Branched by its release number or "branched", and Rawhide by its
@@ -245,9 +261,21 @@ 

          default=False,

          help="Not to run for alternate architectures",

      )

+     parser.add_argument(

+         "--with-coreos",

+         action="store_true",

+         default=False,

+         help="Add packages configured as gating in CoreOS CI config",

+     )

      return parser.parse_args()

  

  

+ # Things that aren't as easy to express via argparse

+ def validate_args(args):

+     if args.with_coreos and not args.srpm:

+         raise Exception("--with-coreos requires --srpm")

+ 

+ 

  def write_files(critpath, outpath, jsonout):

      wrapped = {"rpm": critpath}

      with open(jsonout, mode="w", encoding="utf-8") as jsonoutfh:
@@ -326,6 +354,11 @@ 

              else:

                  critpath[group].update([pkg.name for pkg in pkgs])

  

+         # note for these, we don't do any depsolving

+         if args.with_coreos:

+             coreos_gated_srpms = get_coreos_gated_srpms()

+             critpath[COREOS_CRITPATH_GROUP].update([srpm['name'] for srpm in coreos_gated_srpms])

+ 

          del pkgdict

          print()

      # Turn sets back into lists (so we can JSON-dump them)
@@ -337,6 +370,7 @@ 

  

  def main():

      args = parse_args()

+     validate_args(args)

      release = args.release

      if release == "all":

          relnums = get_bodhi_releases()

The Fedora CoreOS team would like to start gating Bodhi updates on
CoreOS tests passing.

This patch adds a new --with-coreos switch to critpath.py
which will make it reach out to the CoreOS CI configuration file to
know which packages are marked as gating and generate a synthetic
critical-path-coreos group in the output critpath.json.

Currently, ONLY PACKAGES OWNED BY THE COREOS TEAM ARE GATED. Gating
on other packages will be discussed via a future Change Proposal. The
short-term goal is to make sure this is working well before opening
it up.

It's likely the code here will change once we do that, though how
exactly is intimately tied to previous discussions around gating and
the notion of critical path. Currently, they are bound together; we will
have to discuss whether it makes sense to keep it that way or separate
the concepts. Previous discussions on this in:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PLMXRKKDYNJN2LBPJEJBWWA3HL6W2FVC

The new functionality is purely opt-in for now to make it safe but easy
to experiment with.

See also: https://github.com/coreos/fedora-coreos-tracker/issues/1617

this doesn't really seem to respect the behavior of the script wrt binary vs. source package names. for all other cases, the script outputs binary package names unless --srpm is passed. It looks like this will always output source package names for CoreOS.

Bodhi uses source package names, so this isn't fatal, but it is kinda awkward, and will mean if someone wants a list of binary critical path packages, the script says it's giving them that, but for CoreOS, it won't be...

also note this should not be merged without a corresponding change to https://pagure.io/fedora-infra/ansible/raw/main/f/roles/openshift-apps/greenwave/templates/fedora.yaml . All critical path groups that critpath.py causes to 'exist' so far as Bodhi is concerned MUST also exist in at least the kojibuild_bodhipush_no_requirements policy in that file, because if Bodhi queries greenwave for a decision context that doesn't exist in greenwave, the request actually fails catastrophically and Bodhi will always consider the update to have failed gating. So we should always add new groups to fedora.yaml first for safety, then add them here.

this doesn't really seem to respect the behavior of the script wrt binary vs. source package names. for all other cases, the script outputs binary package names unless --srpm is passed. It looks like this will always output source package names for CoreOS.

Bodhi uses source package names, so this isn't fatal, but it is kinda awkward, and will mean if someone wants a list of binary critical path packages, the script says it's giving them that, but for CoreOS, it won't be...

Yeah, this is very optimized for the Bodhi case. I could fix that, but... again it's possible this code will be irrelevant if we e.g. start parsing lockfiles once we open this up. I can explicitly error out if --srpm isn't passed if that helps.

also note this should not be merged without a corresponding change to https://pagure.io/fedora-infra/ansible/raw/main/f/roles/openshift-apps/greenwave/templates/fedora.yaml . All critical path groups that critpath.py causes to 'exist' so far as Bodhi is concerned MUST also exist in at least the kojibuild_bodhipush_no_requirements policy in that file, because if Bodhi queries greenwave for a decision context that doesn't exist in greenwave, the request actually fails catastrophically and Bodhi will always consider the update to have failed gating. So we should always add new groups to fedora.yaml first for safety, then add them here.

Yes, this is done in https://pagure.io/fedora-infra/ansible/pull-request/1758 but I guess I'll have to split up those two commits so that it doesn't depend on this one.

Yes, this is done in https://pagure.io/fedora-infra/ansible/pull-request/1758 but I guess I'll have to split up those two commits so that it doesn't depend on this one.

Well actually, no I think it can be kept together. The logic here is completely inert and won't change the output until https://pagure.io/fedora-infra/ansible/pull-request/1758 is merged, which is also the PR that adds it to the greenwave policy.

I can explicitly error out if --srpm isn't passed if that helps.

Yeah, I think I'd like that.

rebased onto 51b0dffba356f33294846afd79cd29c95f10ccd7

3 months ago

I can explicitly error out if --srpm isn't passed if that helps.

Yeah, I think I'd like that.

Ack. Updated!

If there's nothing else, can someone merge this? Would love to make progress on this. :) Note again that the new logic here is gated by an off-by-default switch.

Why aren't the coreos critpath packages defined in comps like everything else? Our existing tooling already picks up those...

Why aren't the coreos critpath packages defined in comps like everything else? Our existing tooling already picks up those...

Thanks for looking!

FCOS operates differently. Our composes don't use comps and the source of truth for the package set is in the manifests (https://github.com/coreos/fedora-coreos-config/tree/testing-devel/manifests).

Now, this isn't too different from the Atomic desktops, which do indirectly use comps via the comps-sync.py script. However, the FCOS package set is much more opinionated and tightly controlled. (E.g. we have a whole process to follow just to add packages: https://github.com/coreos/fedora-coreos-tracker/blob/main/.github/ISSUE_TEMPLATE/new-package.yml).

But the biggest difference is again, we want to keep the manifests as source of truth.

Another thing to note though is as mentioned in the PR description, the logic here will likely change or be removed once we're ready to open this up to all packages in FCOS. We need to have more discussions about whether/how to separate the concepts of critpath and gating.

rebased onto 507b0c9

3 months ago

ok, lets merge. Note that this gets run from a openshift cronjob pod after a while, so it will be a bit before it's 'live'.

Pull-Request has been merged by kevin

3 months ago
Metadata