<dustymabe>
jlebon: anything waiting on my review that you know of? link me to it
<jlebon>
dustymabe: not yet, will try to circle back on the cosa PR today. just trying to diagnose that podman push issue first
<dustymabe>
👍
<dustymabe>
jlebon: since you are close to it right now (my memory fails me) - right now if we run the release job multiple times does the push container stuff properly do nothing if a container already exists in a remote registry at that version or does it blindly push?
<jlebon>
dustymabe: it will blindly push but be like a no-op since all the layers will already exist
<dustymabe>
but will the manifest that gets created have the same hash and everything? i.e. will anything change?
<dustymabe>
Maybe we should update the code to look at the meta.json and not push if an entry for that container (with digest and all) already exists
<jlebon>
ouhhh, that's a good question. i'm not sure.
<jlebon>
i just tested this locally and did `podman manifest create` twice for the same image and got different hashes, so yeah it would change the hash
<jlebon>
likely there's timestamps in there
<dustymabe>
likely
<jlebon>
SGTM re. meta.json check
<jlebon>
maybe with a --force to override
<dustymabe>
yeah, i'm not sure how we would plumb that through in the job though
<jlebon>
the `--force` would be for local dev
<dustymabe>
yeah, I could see wanting it in the pipeline, but I think we'd need a force knob for each piece of the release job (aws replication, aliyun replication, push container) and that would be a lot of knobs
<jlebon>
actually, interesting you brought that up. i've been thinking of adding that check to `podman manifest create` for a different reason (while reading https://issues.redhat.com/browse/MCO-392)
<dustymabe>
we could use a global knob but i'd rather not force push over things that already existted
<jlebon>
yup, agreed
<dustymabe>
jlebon: can you elaborate on how that issue relates?
gursewak has quit [Ping timeout: 252 seconds]
<jlebon>
it seems like the latest approach is to not ship both the legacy and modern in 4.12 and we want to use the same `oscontainer` top-level key.
<jlebon>
legacy and modern *oscontainer
<jlebon>
i'll add checks in the pipeline that we don't try to push both, but we should also add safety checks in cosa proper
<jlebon>
for local devs hacking on this stuff
<dustymabe>
i.e drop the `base-oscontainer` top level entry?
<jlebon>
walters' idea was to have them be the same, but i'd like to propose dropping it from the schema after we branch cosa for 4.12, yeah
<dustymabe>
so for the "check" I'm thinking we'd add something here that just looks at the container in the registry (the manifest listed one) and says "does the targets of this container match the digests of what we'd push?" If so then no-op.
<jlebon>
hmm, i think we'd need to compare the arch-level digests though and not the manifest-listed one
<dustymabe>
right - hence my wording of `targets` and `digests` above
<jlebon>
ahhh ok, i got confused
<dustymabe>
I don't know if we can reliably get the information
<dustymabe>
but the idea is "pull remote manifest that already exists in registy -> get target arch containe digests -> compare with what we are about to push -> no-op if no change"
<jlebon>
yup, makes sense. you should be able to get it from `skopeo inspect --raw` (see `cmd-copy-container`)
<jlebon>
get them*
<dustymabe>
ok i'll create an issue for this and see if jmarrero wants to tackle it
<dustymabe>
jlebon: regarding the file locking for the extensions container.. did you want to tackle that or do you want me to create an issue for it and see if someone else wants to pick it up?
<jlebon>
dustymabe: let's create an issue, thanks!
<dustymabe>
ok /me writes issues
<jdoss>
walters: I spent the evening trying to reproduce the rpm-ostree lockup when switching container versions with exact steps with workflow that was not my production stuff and I can't get it to reproduce. I burned down my production stuff and started over and I can't reproduce there either anymore, so I am not going to open the issue unless you want to see my writeup.
<dustymabe>
it was a trivial change since our site is bespoke and fully fleshed out already (we built it custom to display our stream model) so all we had to do was just move the tile on the main page up to the next level
<jlebon>
actually, the rebase checklist doesn't call for doing a git-level sync, which I thought it did
<bgilbert>
yeah, I've now added a checklist entry, but it's not clear to me that whoever's doing the promotion will be looking at the checklist at the time
<jlebon>
dustymabe: shouldn't the section "Preparing for Fedora (N) GA" say to take at least e.g. the lockfile from next rather than doing `--update-lockfile`?
<dustymabe>
i've got some local notes/updates for the instructions
<dustymabe>
let me post them up somewhere and see if that addresses open questions