Hey, we announced image mode for RHEL: https://www.redhat.com/en/blog/introducing-image-mode-red-hat-enterprise-lin...
It's tech preview, but I think it'd make sense to move these images into centos proper still.
Right now we have upstream code in https://github.com/centos/centos-bootc and we created a temporary quay.io namespace in quay.io/centos-bootc.
I'd like to propose a migration like this:
- github.com/centos/centos-bootc -> https://gitlab.com/redhat/centos-stream/containers/bootc (Somewhat paralleling https://gitlab.com/fedora/bootc/base-images ) This would also implicitly be creating a new containers/ namespace) - quay.io/centos-bootc/centos-bootc:stream9 -> quay.io/centos/centos-bootc:stream9 - quay.io/centos-bootc/bootc-image-builder:latest -> quay.io/centos/bootc-image-builder:latest
The :latest tag is currently a bit out of place for bib, and should probably switch to :stream9 too? That said, the time may also be right at least for these things to convert from a ":stream9" tags in favor of a more...streamlined tag like just plain ":9"?
Only tangentially related, but still related is
$ skopeo inspect -n docker://quay.io/centos/centos:latest|jq -r .Created 2020-12-08T00:22:53.076477777Z $
Which is obviously pretty broken...we should probably just drop this `:latest` tag as it's just a trap at this point?
On Tue, May 14, 2024 at 12:16 PM Colin Walters walters@verbum.org wrote:
Hey, we announced image mode for RHEL: https://www.redhat.com/en/blog/introducing-image-mode-red-hat-enterprise-lin...
It's tech preview, but I think it'd make sense to move these images into centos proper still.
That sounds like a great idea.
Right now we have upstream code in https://github.com/centos/centos-bootc and we created a temporary quay.io namespace in quay.io/centos-bootc.
I'd like to propose a migration like this:
- github.com/centos/centos-bootc ->
https://gitlab.com/redhat/centos-stream/containers/bootc (Somewhat paralleling https://gitlab.com/fedora/bootc/base-images ) This would also implicitly be creating a new containers/ namespace)
- quay.io/centos-bootc/centos-bootc:stream9 ->
quay.io/centos/centos-bootc:stream9
- quay.io/centos-bootc/bootc-image-builder:latest ->
quay.io/centos/bootc-image-builder:latest
The :latest tag is currently a bit out of place for bib, and should probably switch to :stream9 too? That said, the time may also be right at least for these things to convert from a ":stream9" tags in favor of a more...streamlined tag like just plain ":9"?
Everything else is "stream9". Names, directories, alot of things. Halfway through a products lifecycle doesn't seem like the time to streamline things. Other than that, I think this looks good.
Only tangentially related, but still related is
$ skopeo inspect -n docker://quay.io/centos/centos:latest|jq http://quay.io/centos/centos:latest%7Cjq -r .Created 2020-12-08T00:22:53.076477777Z $
Which is obviously pretty broken...we should probably just drop this `:latest` tag as it's just a trap at this point?
You are correct, we need to either update this each time the latest container is updated (currently stream9) or remove it. Can you open a Jira issue against the CentOS Stream Pipeline team.
On a related subject. Do you see this work being transferred to the CentOS Stream team when it comes out of tech preview? They are the team that makes the containers.
Troy
On Tue, May 14, 2024, at 4:30 PM, Troy Dawson wrote:
Everything else is "stream9". Names, directories, alot of things. Halfway through a products lifecycle doesn't seem like the time to streamline things.
Yeah, agreed.
Other than that, I think this looks good.
OK so, any who can own/help with that? Right now we have a Konflux pipeline. Ideally in the more medium term, we share procedures with whatever produces quay.io/centos/centos:stream9. And speaking of, what does produce that now and where is its source?
You are correct, we need to either update this each time the latest container is updated (currently stream9) or remove it. Can you open a Jira issue against the CentOS Stream Pipeline team.
https://issues.redhat.com/browse/CS-2159
On a related subject. Do you see this work being transferred to the CentOS Stream team when it comes out of tech preview? They are the team that makes the containers.
Yes - but we'll need to bear in mind this container is very actively developed and has a lot more going on related to it than the existing "app" base image, so in practice the team working on it would need to be working at least pretty closely with any other release engineering teams.
On Wed, May 15, 2024 at 8:58 AM Colin Walters walters@verbum.org wrote:
On Tue, May 14, 2024, at 4:30 PM, Troy Dawson wrote:
Everything else is "stream9". Names, directories, alot of things. Halfway through a products lifecycle doesn't seem like the time to streamline things.
Yeah, agreed.
Other than that, I think this looks good.
OK so, any who can own/help with that? Right now we have a Konflux pipeline. Ideally in the more medium term, we share procedures with whatever produces quay.io/centos/centos:stream9. And speaking of, what does produce that now and where is its source?
I think we should, as a project, look more earnestly at Konflux itself. That would likely be better than the existing tooling we have for building containers today.
You are correct, we need to either update this each time the latest container is updated (currently stream9) or remove it. Can you open a Jira issue against the CentOS Stream Pipeline team.
https://issues.redhat.com/browse/CS-2159
On a related subject. Do you see this work being transferred to the CentOS Stream team when it comes out of tech preview? They are the team that makes the containers.
Yes - but we'll need to bear in mind this container is very actively developed and has a lot more going on related to it than the existing "app" base image, so in practice the team working on it would need to be working at least pretty closely with any other release engineering teams.
I don't understand how Tech Preview in RHEL matters in terms of who is building the images. Support stance in RHEL is irrelevant in Stream. The work has to happen either way.
josh