#1021 Internal db state for retired modules
Closed: Fixed 4 months ago by mprahl. Opened 8 months ago by ralph.

This was triggered by #963.

Today, in Fedora, when a module is retired with fedpkg retire ... things are successfully changed so that you cannot build the module any more.

However, things can still build on your module (use your module as a buildrequires). In particular, if the module is a platform pseudo-module and we want to retire that old stream, we don't really have a way to stop people from building on that old stream. Stream expansion may make people automatically build on your module.

We should add a new state for modules in the db "retired" so we can transition these old streams into a state where they cannot be built against (using stream expansion, or otherwise).

mbs-manager should provide a command for admins only to "retire" module builds. It should accept any of:

  • A NSVC, in which case that NSVC is retired.
  • A NSV, in which case all contexts of a NSV are retired.
  • A NS, in which call all contexts of all versions of a NS are retired.

All of these should prompt "Are you sure?" and show the list of the module builds that would be retired, before proceeding.


@ralph what do you think about automating this by having a microservice listen on the message bus for fedpkg retire commits on modules in dist-git? The modules API endpoint already supports the PATCH HTTP method, so it wouldn't be much code to support this.

@ralph @mprahl Has there been any planning/progress towards providing the ability to mark modules as retired/obsolete/dead?

How often does retiring a module happen? If it's not often enough I think having a microservice might have the downside of going down and no one noticing. I'd prefer to have an explicit action for this if possible.

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #1124 Merged 4 months ago