hhorak reported a new issue against the project: `atomic-wg` that you are following: `` 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..
What do you think? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
smilner added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
cverna added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
hhorak added a new comment to an issue you are following: `` What? Bodhi supports containers already? Or is it something soon-to-be-deployed? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
cverna added a new comment to an issue you are following: `` 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
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
hhorak added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/466
atomic@lists.stg.fedoraproject.org
-
Clement Verna -
Honza Horak
-
Steve Milner