Support pulling new releases into CentOS Stream

[lbarcziova]

• [x] Prefilter the Anitya events in fedmsg & pass them to the Service
  • packit/packit-service-fedmsg#91
  • packit/deployment#536
• [x] Parse the Anitya's version update event in the Service
  • packit/packit-service#2348
• [x] #2408
• [x] #2440
• [ ] ⚠️ Choosing the correct version
  • Outcomes from the arch:
    • Gather more use cases
    • Require the explicit setting for version mask (for CentOS at least)
• [ ] ⚠️ Decide whether to support Fedora for Anitya version update too… right now it's prefiltered for the CentOS
• [ ] Implement prechecks that we're missing now https://github.com/fedora-infra/the-new-hotness/blob/363acd33623dadd5fc3b60a83a528926c7c21fc1/hotness/hotness_consumer.py#L461
• [ ] Adjust the Packit config retrieval — needs to be taken from the CentOS dist-git
• [ ] Adjust the sync-release if necessary

CC @cathay4t

[mfocko]

I had a look at it… It is a bit more complicated to resolve:

• parsing is not affected that much, yet
  • we should make sure we're using the correct package name for both Fedora and CentOS
  • we should include the CentOS dist-git
• handling of the CentOS v. Fedora should be separated, since they depend on the dist-git included in the API and we can have only one dist-git, duh…
  • having a separate “package” (one for Fedora, one for CentOS) in Packit config might ease this a lot, since there are different dist_git_branches and each “package” would have its own downstream counterpart, there would be 2 separate Celery tasks for handling this, thus resolving the PackitAPI issue
• given the two points above, it would probably make sense to extend the event to hold dist-git URLs instead of just the one

[lbarcziova]

The person who will pick this should make sure this is everything that needs to be changed and in case there is more, create follow-up issues.

[nforro]

I wonder if this actually makes sense. We react to org.fedoraproject.prod.hotness.update.bug.file messages, which effectively means release-monitoring.org projects that have Fedora mapping configured and monitoring enabled at src.fedoraproject.org. Shouldn't we rather react to org.release-monitoring.prod.anitya.project.version.update messages and check for Fedora/CentOS mapping and continue from there?

[lachmanfrantisek]

@nforro Thanks for bringing this up.

If I remember correctly, we've picked this option to have some pre-filtering done by the New Hotness but I am now not sure, what pre-filtering is being done here and if it still makes sense. We can ask Michal.

[nforro]

Yes, I suppose the monitoring option in Pagure does filter out some unwanted traffic, and it makes complete sense to take advantage of it in Fedora, but not so much in CentOS. What if there is a package that is EL-only?

[lbarcziova]

@nforro is right that the messages we currently listen to are filtered in a way that there needs to be mapping to Fedora for the particular package. Besides that, New Hotness does other prefiltering, see the code, e.g. the monitoring enabled in Fedora dist-git, whether the version is newer, whether the package is not retired etc. If we want to support CentOS only packages, we would need to do what Nikola proposes. And in that case, maybe implement the additional checks ourselves.

[mfocko]

Architecture discussion notes

• keep reacting to org.fedoraproject.prod.hotness.update.bug.file for Fedora
• org.release-monitoring.prod.anitya.project.version.update for CentOS (and potentially if an RFE occurs for older releases of Fedora)
• keep in mind not to react to both for Fedora (i.e. don't create duplicate PRs)
• check the events for potential naming discrepancies between Fedora and CentOS
  • rely on users to make sure they're correct

[ckelleyRH]

@mfocko - FYI I am happy to do "real world" battle testing of Packit -> CentOS Stream things as and when it is useful. I am part of the OSCI team responsible for Stream/RHEL and I have some packages in Fedora/Stream/RHEL that I maintain primarily to dogfood the whole packaging experience holistically.