cmd/list: Recognize UBI images #776
Conversation
HarryMichal
added
6. Minor Change
|
Build failed.
|
HarryMichal
force-pushed
the
list/ubi-images
branch
from
7b9f7ad to
83ee6c7
Compare
|
Build failed.
|
HarryMichal
force-pushed
the
list/ubi-images
branch
2 times, most recently
from
12254d1 to
f736f79
Compare
|
Build failed.
|
HarryMichal
force-pushed
the
list/ubi-images
branch
from
f736f79 to
e19866e
Compare
UBI[0] does not have the recommend Toolbox labels used to track whether an image/container is truly a toolbox image/container. Thankfully, they have a number of labels to choose from that we can use to identify the image. The "com.redhat.component=ubi8-container" seems to be ideal. The approach of using the UBI8 label introduces one problem though. If we were to use only one set of labels for both images and containers, containers created with Podman and not Toolbox from UBI8 would also be marked as toolbox containers. This is not desired and therefore there are now two sets of labels. Ones for images where the new label has been added and other for containers that stays the same.
HarryMichal
force-pushed
the
list/ubi-images
branch
from
e19866e to
ebd799f
Compare
|
Build succeeded.
|
Fallout from containers#776 containers#782
There was a problem hiding this comment.
Let's hold this back for a bit.
I understand that not listing the corresponding image for UBI Toolbox containers is a rough edge. However, the whole UBI feature is a bit experimental. The concept of Toolbox, even if it's only a Fedora container on a Fedora host, itself is quite new. With UBI we are talking about a free RHEL environment created just like that on any Linux distribution.
So it's ok, if we take a release or two to hammer out the details. Especially since we are very likely going to get a Toolbox-specific image that's created out of the UBI RPM repositories.
There's also the issue that we really want to get 0.1.0 done, and we really need to keep the churn down for that. Changing the labels can very likely lead to backwards compatibility issues in the future, where we get stuck with a non-ideal label for a while. We managed to get rid of some our past labels, so let's not add more to the list.
In short, this bug will likely fix itself in the coming months. So let's not get ourselves into a corner trying to rush through a fix.
| // toolboxContainerLabels holds labels used by container that mark them as compatible with Toolbox | ||
| toolboxContainerLabels = map[string]string{ | ||
| "com.github.debarshiray.toolbox": "true", | ||
| "com.github.containrs.toolbox": "true", |
There was a problem hiding this comment.
Nitpick: typo alert! containrs.
See #792 |
Requires #774
Fixes #753