Conversation
Add check for image existing in local backends, which allows for 'atomic.type=system' labelled containers to be installed without an extra remote check. Signed-off-by: Yu Qi Zhang <jerzhang@redhat.com>
|
@yuqi-zhang Isn't this a problem though, that you have already pulled the image and stored it probably in docker, we want it directly installed in --ostree. |
|
Sorry, I'm not quite sure what you mean, do you mean a case where the image is locally in docker already, but has a 'atomic.type=system' label? Then yes that is an edge case where if there is a local docker image AND the user doesn't specify --system or --storage, the CLI would assume the image should be installed as a docker container. This behavior did not change from the old code. I feel like we should allow users to do that, since for an image with 'atomic.type=system' to have been pulled to docker, the user must have specified --storage=docker to override it. The user may want to run it as a docker container for other reasons. Locally built images are another edge case, and perhaps should be re-considered. |
|
I have no problem with the local case. But I am more interested in the remote case. A user doing atomic install registry.access.redhat.com/etcd-system Should be installed as a system container. |
|
I have tested that case, it would work if registry.access.redhat.com/etcd-system has 'atomic.type=system'. I did not change this logic. The only caveat is that if docker isn't running, since the remote inspect calls all the way down to https://github.com/projectatomic/atomic/blob/master/Atomic/util.py#L63 it will fail with |
|
Excellent, if that use case works. |
|
@giuseppe PTAL |
|
this change LGTM, we shouldn't require Docker running to get install a system container |
|
☀️ Test successful - status-redhatci |
5 participants
Add check for image existing in local backends, which allows for
'atomic.type=system' labelled containers to be installed without
an extra remote check.
Signed-off-by: Yu Qi Zhang jerzhang@redhat.com