#102 Block modules when their service levels are expired
Opened 6 months ago by mohanboddu. Modified 4 months ago

Currently there is no way to block a module build going into compose if its service level is expired.

So, couple of things to look at here:
1. If the packager is still building them, then they're probably not actually EOL
So, we most likely just want a git hook to remind them to extend the service level.
2. Since their service levels are expired, we might not want them ending up in our composes.
Here, probably we need pungi to check the service levels and eject EOLed content from composes.

I am also including the discussion on irc with @sgallagh

[14:14:27] <mboddu> sgallagh, threebean or anyone: How can I block a module in koji, so that it wont be built and wont end up in composes?
[14:14:47] <sgallagh> mboddu: I think just untag it?
[14:15:02] <sgallagh> Or do you mean for mass-rebuilds?
[14:15:07] <mboddu> sgallagh: But they can still build it again
[14:15:24] <sgallagh> mboddu: What problem are you trying to solve?
[14:15:41] <mboddu> sgallagh: For ex: if a stream is eol'd, then I dont want people building modules from that stream and ending up in composes
[14:16:42] <sgallagh> mboddu: Probably we need pungi to check the servicelevels and eject EOLed content from rawhide composes.
[14:17:08] <sgallagh> But for stable composes, I think we need to allow them to remain, even past EOL, for the sake of not breaking end-users.
[14:17:18] <sgallagh> Just because they're EOL doesn't mean people instantly stop needing them
[14:17:29] <contyk> +1
[14:17:50] <contyk> also we don't have a place to store EOL data now, with PDC going away
[14:17:56] <sgallagh> whee
[14:17:56] <mboddu> sgallagh: True, I am not asking to remove them, I am asking to not to build anymore and not to put them in repos anymore
[14:18:12] <sgallagh> mboddu: I'm not sure that needs enforcement
[14:18:26] <sgallagh> If the packager is still building them, then they're probably not actually EOL
[14:18:33] <contyk> yeah
[14:18:36] <sgallagh> (And we most likely just want a git hook to remind them to extend the servicelevel)
[14:22:13] <mboddu> sgallagh: How can a maintainer update the service level? As he doesnt have access to update PDC directly?
[14:22:38] <sgallagh> mboddu: https://pagure.io/rpkg/issue/328
[14:22:40] <mboddu> sgallagh: Also, update pungi to check the servicelevels and eject EOLed content from rawhide composes and add a git hook to remind them to extend the service level(depends on ^), I like both, can we look at adding them?
[14:23:44] <sgallagh> mboddu: The servicelevel stuff is in progress
[14:24:00] <sgallagh> And yeah, both of those should probably have a Jira card, though I'm not sure on which board :)
[14:25:09] <sgallagh> mboddu: Maybe file those on https://pagure.io/modularity/issues for now?
[14:26:06] <mboddu> sgallagh: Interesting, and I dont think https://pagure.io/rpkg/issue/328 is possible as fedpkg dont have access permissions to update PDC, hence eol's on component branches are updated when fedpkg retire is called by calling a handler(https://github.com/fedora-infra/pdc-updater/blob/develop/pdcupdater/handlers/retirement.py)
[14:26:59] <mboddu> sgallagh: Probably we need another service like that, listen and update PDC :)
[14:27:20] <mboddu> I will create the tickets for it, thanks
[14:28:50] <sgallagh> mboddu: I don't know the details there, but with the PDC retirement I was assuming that a lot of things are in fluc
[14:28:53] <sgallagh> *flux
[14:30:10] <mboddu> sgallagh: Yeah, anyway, just pointing it out that its not possible directly atm, but good to keep in mind for whatever that is going to replace PDC
[14:30:17] <sgallagh> ack


+1 to the git hook.

Probably -1 to the pungi suggestion. This could be implemented in MBS, which could simply not tag the module into the candidate tag. Could be implemented as part of the configurable tagging policy feature.

Anyway, we don't have a place to store these anymore. This is effectively blocked until we find a new place to keep this data.

Metadata Update from @psabata:
- Issue tagged with: Blocked

6 months ago

Package blocking for modules should probably work "the same way" it does for rpms. If the module is blocked in koji, then don't include it in the compose. If the module is blocked in koji, then new builds of it should fail.

  • The first thing to check would be to see if the ansible/roles/bodhi2/backend/templates/owner-sync-pagure.j2 script really does block modules in the modular tags when their eols expire.
  • Once blocked in the relevant koji tags, I feel fairly certain that koji would prevent new builds of it (the CG import, the last step).
  • We would need to verify that blocking the module's package in the modular tag would prevent pungi from picking up old builds of the module. (Is that what we want? For old builds of the module to disappear from rawhide? I think so.)

As for the PDC FUD, see the ongoing infra discussions. Looks like the plan is to split out the branch/SL/EOL endpoints into their own service and to introduce some simplifications for release (non-stream) branches.

The more I think about it, I see more problems

@ralph I dont think we can just block modules as we do with packages in koji, since we want to block a particular stream because its the stream got EOL'd not the entire module.

We would need to verify that blocking the module's package in the modular tag would prevent pungi from picking up old builds of the module. (Is that what we want? For old builds of the module to disappear from rawhide? I think so.)

I think that is what we want. But how can we do this? Unlike in rpm world, where you are sticking to providing support until the end of the release, so once its built we can keep it for the entirety of that release. But in modular world that is not the case and if we dont find some solution to this, we might end up in providing unsupported modules.

I dont think we can just block modules as we do with packages in koji, since we want to block a particular stream because its the stream got EOL'd not the entire module.

... ack. Good catch. :/

Well, breaking the problem down:

We need to prevent:

  • Building EOL'd module streams.
  • Composing with EOL'd module streams.

I guess MBS will need to learn about the first part, and pungi will need to learn about the second part.

First thing first ( I think we already have this setup, but if not we need to add this)
fedpkg retire should put a dead.package in the stream they are targeting to retire and update PDC with the eol date with current date.

I guess MBS will need to learn about the first part

Thats what I am thinking, mbs will talk to PDC(or whatever the newer thing is called) to check the EOL and if that stream is retired then print something like "Module Blah is retired for blahblah stream" :smile:

pungi will need to learn about the second part

May be, but what about mirrors?

I think mirrors should be fine if they use rsync with --delete option, which is what I think they are doing. (Correct me if I am wrong, as my knowledge on mirror manager is minimal :disappointed: )

I think mirrors should be fine if they use rsync with --delete option, which is what I think they are doing. (Correct me if I am wrong, as my knowledge on mirror manager is minimal 😞 )

Note: we do NOT want to remove EOLed streams from stable releases. We want to only block them from Branched/Rawhide (and possibly EPEL if it grows module support one day). It's okay for EOLed streams to remain on the mirrors for stable releases as users may still be relying on them. They're just not going to get updates.

Yeah, we are not supposed to remove content from stable releases, only on branched and rawhide we need to remove.

Login to comment on this ticket.

Metadata