fesco

#2049 Container update policy update
Closed: Invalid by churchyard. Opened by jcajka.

Closed: Invalid
Reopen Issue

Based on the discussions that we have had in the container SIG(part recorded here), there is need to adjust the current container update policy in the bodhi.

For the context as bodhi updates has been introduced for the containers we used the same update policy that is used for the RPM packages in Fedora. That means 7days in testing without negative karma or +3 karma. This causes us large overhead for every update and even more significant overhead for inter depended/layered containers as there is no notion of batched updates or "push to buildroot".

We would like to shorten the required time to 1day in testing and no negative karma or +3 karma.

I do not expect any significant negative impact of this change as all components of the containers/RPMs have already passed the regular update/testing cycle. To note we would like to introduce further automation and testing/CI, but all of that is in very early stages of discussion.

What is your opinion? Do you approve this change?

CC'ing @cverna

1 day is a pretty small window for someone to provide feedback.

Would the autopush on time help here any? (ie, keep it longer, but it automatically goes to stable after the timeout and no negative karma)

@kevin I believe, I like that idea. Un-push should be possible, I guess, only possible pain point I see with tracking layered images(on top of that auto pushed image, but this is general issue, not specific to this case).
Is it possible now with bodhi or does it need to be implemented?

About 10 months ago I attempted to add support for BuildrootOverrides for containers to Bodhi:

https://github.com/fedora-infra/bodhi/issues/2018

At the time it was difficult to achieve, because container images cannot be untagged with the Docker registry API. If you ask the registry API to delete a tag, it deletes the image, not just the tag, meaning that if the image is tagged with other tags, those tags are removes as well. Fun, right?

Anyways, a common workaround to this problem is to push up an empty container under the tag name you want to remove, and then delete that image (effectively removing the tag without removing the original image). I started down this path, but then the problem arose: how do I get an empty container image in Bodhi that I can push to the repository to achieve this? I didn't want to check in a "magic" file to Bodhi's git repository for this, but building container images required root a year ago. I ended up putting the ticket down after that because other things came up and that ticket was mired in these problems.

Fast forward to now, we finally have a way to build an empty container image without root using builah, so I think that solution might finally be viable.

All that to say, if we add buildroot override support for containers to Bodhi, would that address your concerns?

I'm electing not to put this on the agenda for today, since we're awaiting feedback from the submitters.

@bowlofeggs I it would be great, possibility for overrides and "batches". Although I would still prefer the update policy change until this is in the place.

How much work that would require? I have planned to have this discussion at DevConf as we will meet in container-sig f2f.

1 day is a pretty small window for someone to provide feedback.

I think we don't want people wasting time to test containers and provide feedback on them.

We have the beginning of a CI pipeline in place for containers ideally containers should be gated only on the CI results.
See here example of a container CI test (https://src.fedoraproject.org/container/tools/pull-request/6)

Generally I tend to think that karma and testing window is not really relevant for containers. If a container update does not work the user can still use a previous working tag moreover a broken container will not make the user system unstable.

Would the autopush on time help here any? (ie, keep it longer, but it automatically goes to stable after the timeout and no negative karma)

After today's FESCO meeting we reached the agreement to leave the 7 days policy in place but to require only +1 karma for container updates.
Unfortunately the karma cannot be set by release so this will have to be done manually for the time being when creating the update.

The Container SIG will be helping maintainer with testing the updates and provide Karma for them.

On Mon, 2019-01-14 at 13:04 +0000, Jakub =C4=8Cajka wrote:

How much work that would require?

I think it would take me somewhere between 1 and 3 days to do it. The
problem is that I already am overcommitted for 2019 so I can't commit
to do it myself. Patches welcome, of course =E2=98=BA

@bowlofeggs I think that I'm in similar situation. Are you planning to visit Devconf? It would be great if you could stop by Container-SIG meetup https://sched.co/K8nC and we could discuss that.

After today's FESCO meeting we reached the agreement to leave the 7 days policy in place but to require only +1 karma for container updates.

AFAIU this is also the policy for normal RPM packages. The wording just hides this:
https://fedoraproject.org/wiki/Updates_Policy#All_other_updates

Metadata Update from @churchyard:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

Closing as invalid as in "no longer needed".

Please reopen or comment if I got it wrong.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.