[LOS-455] add script to faciliate manual 'refreshes' of individual repos within a snapshot

added 5 commits

• 66870680...17df3e06 - 4 commits from branch master
• 17576f92 - [LOS-455] add script to faciliate manual 'refreshes' of individual repos within a snapshot

Compare with previous version

assigned to @airibarr

I think this script should not modify the 8 or even 8-testing symlinks, but instead work directly with 8-snapshots/$TODAY. Modifying today's snapshot minimizes the damage you can do, but the further in time you go, the more problems you can cause. For example, you could add SIG packages to last week's snapshots with dependencies that aren't available in last week's base repos.

A safer procedure would be to refresh today's snapshot and move the symlinks, if necessary. We shouldn't refresh snapshots except in case of an emergency, and in that case moving the symlinks would be justified.

added 1 commit

• b3926f2a - refactor script

Compare with previous version

I see this script solving two valid use cases:

1. daily centos8_snapshots has already run, but upstream cloud SIG have released packages that IT-CM-RPS need today. We can run this script to refresh just the cloud SIG. In this scenario we don't want to modify the symlinks as we only care about having the new cloud content available. This use case would only make sense to update the snapshot behind '8-testing' (and having their koji tags defined to use 8-testing, like we currently do for cloud in CC7).

2. We have a patch in 8-testing/CERN that nobody complains about, but it breaks some things in production once that snapshot is promoted to '8'. After we fix the broken thing in the CERN repo, we can use this script to sync. Here we would most likely want to be able to touch '8' and '8-testing' snapshots as finding $brokenthing may not occur on the same day as the production release (hence moving the symlinks forward could bring many changes forward that we may not want to promote).

I've updated the code to only allow modifications for SIGs against '8-testing'. I've also renamed the file to 'c8refreshrepo' and changed the code to source config.sh, as per our previous discussion.

1. In this scenario, what you want is to update the cloud SIG in today's snapshot. 8-testing will be pointing to today anyway.

• I'd argue the Cloud team could probably wait a day, but I guess it's good to have the option.

2. Ok, say 8 points to the 1st and 8-testing to the 4th, which is today. You update them both with thing-2.

• Somebody that's using individual snapshots with TODAY-3 (ie., the 1st) will get v2 today. However, tomorrow they'll get downgraded to v1, because that package is not in the snapshot for the 2nd, and then they'll get upgraded again on the 7th.
  • You'd have to modify all the snapshots after the 1st in order to do this safely.
• Additionally, if v2 depends on something that was introduced anytime after the 1st, you've suddenly broken the repo.
  • Now you'd have to build your package against the snapshot of the 1st, making lots of changes in Koji, and then put it in all subsequent snapshots.

Yes, moving the symlinks potentially promotes more things, which isn't great. Still, I think it's the simplest and least risky solution.

Ok, so we agree on point 1. Good :)

For point 2:

If someone is using $TODAY-3, that's only extrapolated for $TODAY - There is no automated mechanism to change the $cernbase yum variable on a daily basis. Your example is not correct. If someone had their snapshot ($cernbase) configured as $TODAY-3, they would be stuck on that snapshot forever. They would get thing-2 (as the content would at this time be the same snapshot as 8), but they would never get any more updates (or downgrades) until they change $cernbase themselves again manually.

Regarding dependencies, we are talking about the CERN repo here. Basic packages that we control the full dependency tree. I don't see how we can break the repo, or why many changes in koji would be required?

Moving the symlinks (https://its.cern.ch/jira/browse/LOS-461) is for sure the simplest approach, though I would argue that it's less risky. The C8 release process should be as predictable as possible, meaning that users should expect only 1 update per week; barring exceptional circumstances.

One feature we have with the bs* workflow is the ability to promote individual packages. Whilst this change doesn't support the promotion of individual packages, it's the next best thing which is individual repo promotion.

closed