Let me describe my frustration from building layered containers in Fedora.
We've been maintaining CentOS and RHEL based images for various interesting stuff like databases (PostgreSQL, MariaDB) or dynamic languages (Python, NodeJS) at http://github.com/sclorg/ and we'd love to see the same set of containers in Fedora as well.
The challenge I see is that we have 2 or 3 layers on top of the base image, e.g.: Fedora 28 -> s2i-core -> s2i-base -> python, which is probably somewhat special, comparing to simple container images that just depend on the base image. The problem is that when we want to build either s2i-base or python, we only can take image from the release registry (registry.fedoraproject.org, mentioned in the guidelines and enforced in the tooling), so if the release would work as expected every two weeks, we can build s2i-core, in 2 weeks we can build s2i-base, and in another two weeks we can have up2date python container that uses some features from s2i-core that we built 4 weeks back.. That is not what we want to see.
And then, there is the release itself, that is still somewhat indeterministic, and we don't see when the built image will be available.
Anyway, when thinking about how to fix this process issue, it looks like everything would be better if layered images from the candidate registry would be used when building a new container. It might be done simply by rewriting FROM (s/registry.fedoraproject.org/candidate-registry.fedoraproject.org/) as such rewrites are done anyway in OSBS... If someone would really like to use the image from released registry, they can use concrete release tag..
FROM
s/registry.fedoraproject.org/candidate-registry.fedoraproject.org/
What do you think?
Metadata Update from @hhorak: - Issue tagged with: build-service
I'm not totally up to date with candidate-registry requirements. My only concern would be releasing a container on a candidate layer that ended up not being released due to a bug/CVE/etc.. yet it's in some released containers but not others. It's not a huge deal as it should then be easy to respin a fixed version quicker than it would if the issue was present in a released layer, but it still is something to think about.
I think the main issue here is not the availability of the candidate-registry but the release cycle.
Thanks to @bowlofeggs bodhi has grown support for containers. We still need to test it and figure out the workflow to use it, but I think being able to create update for containers would solve @hhorak frustrations with the current way of doing things.
What? Bodhi supports containers already? Or is it something soon-to-be-deployed?
The deployed version of bodhi has the code needed to support containers. There are still few bits and pieces needed to be setup in the infra before we can start testing it.
I can see that https://pagure.io/fedora-infrastructure/issue/6874 is needed for example
I still think that fixing bodhi is not enough here, unless all images that are in bodhi would be already available for other images during build. My expectation is (and correct me if I'm wrong) that images will be available for other builds after they pass through bodhi (which takes days) and that case we'd still need to wait several days till the 1st layer (s2i-core) is available in registry.fp.o, then another few days till 2nd layer (s2i-base) is available in registry.fp.o etc..
IOW, what I want to achieve here, considering the 3 layer scenario from above (s2i-core -> s2i-base -> python), is to be able to commit to all three repos at once, and build all three images at the same time (in correct order obviously).
Having the images from the candidate registry available for other builds would allow me to do it, but maybe there is another way to achieve the same thing.
Metadata Update from @cverna: - Issue tagged with: containers
Login to comment on this ticket.