Q: Slightly uncomplicating manifest-lists
All, Recently I wrote a blog article that touches on a few podman (and buildah) commands which are bound to catch people off-guard: https://podman.io/blogs/2021/10/11/multiarch.html Unfortunately the reason for the "Ugh! What? Really?" of 'rm' and 'push' is "maintaining compatibility" - hence, unlikely to change. See https://github.com/containers/podman/issues/11899 So my thinking was, if we can't change the CLI can we make the feedback to users better? At least then, people would be alerted when it comes to surprising 'rm'/'push' behavior. For example: $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/redis latest 7faaec683238 7 days 116 MB reg.fed.org/fedora 34 191682d67252 2 weeks 184 MB ex.co/foo/bar latest [M]123456576b54 1 second 123 GB reg.acc.red.c/ubi8-init latest 670b0e87da3c 4 weeks 251 MB quay.io/libpod/alpine latest 961769676411 2 years 5.85 MB Indicating 'ex.co/foo/bar' is a manifest list not a regular image, and so needs special handling by the user. Alternatively it could be it's own column. I was just wanted to be sensitive to anyone who may be scraping the space-separated data for some purpose. What are your opinions/concerns/alternatives for something like this? -- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer My personal robot overlord told me to include this signature line.
On 10/19/21 11:54, Chris Evich wrote:
All,
Recently I wrote a blog article that touches on a few podman (and buildah) commands which are bound to catch people off-guard: https://podman.io/blogs/2021/10/11/multiarch.html
Unfortunately the reason for the "Ugh! What? Really?" of 'rm' and 'push' is "maintaining compatibility" - hence, unlikely to change. See https://github.com/containers/podman/issues/11899
So my thinking was, if we can't change the CLI can we make the feedback to users better? At least then, people would be alerted when it comes to surprising 'rm'/'push' behavior. For example:
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/redis latest 7faaec683238 7 days 116 MB reg.fed.org/fedora 34 191682d67252 2 weeks 184 MB ex.co/foo/bar latest [M]123456576b54 1 second 123 GB reg.acc.red.c/ubi8-init latest 670b0e87da3c 4 weeks 251 MB quay.io/libpod/alpine latest 961769676411 2 years 5.85 MB
Indicating 'ex.co/foo/bar' is a manifest list not a regular image, and so needs special handling by the user. Alternatively it could be it's own column. I was just wanted to be sensitive to anyone who may be scraping the space-separated data for some purpose.
What are your opinions/concerns/alternatives for something like this?
We should add the field to the end of list. REPOSITORY TAG IMAGE ID CREATED SIZE TYPE docker.io/library/redis latest 7faaec683238 7 days 116 MB Image reg.fed.org/fedora 34 191682d67252 2 weeks 184 MB Image ex.co/foo/bar latest [M]123456576b54 1 second 123 GB List reg.acc.red.c/ubi8-init latest 670b0e87da3c 4 weeks 251 MB Image quay.io/libpod/alpine latest 961769676411 2 years 5.85 MB Image
On Tue, Oct 19, 2021 at 8:35 PM Daniel Walsh <dwalsh@redhat.com> wrote:
On 10/19/21 11:54, Chris Evich wrote:
All,
Recently I wrote a blog article that touches on a few podman (and buildah) commands which are bound to catch people off-guard: https://podman.io/blogs/2021/10/11/multiarch.html
Unfortunately the reason for the "Ugh! What? Really?" of 'rm' and 'push' is "maintaining compatibility" - hence, unlikely to change. See https://github.com/containers/podman/issues/11899
So my thinking was, if we can't change the CLI can we make the feedback to users better? At least then, people would be alerted when it comes to surprising 'rm'/'push' behavior. For example:
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/redis latest 7faaec683238 7 days 116 MB reg.fed.org/fedora 34 191682d67252 2 weeks 184 MB ex.co/foo/bar latest [M]123456576b54 1 second 123 GB reg.acc.red.c/ubi8-init latest 670b0e87da3c 4 weeks 251 MB quay.io/libpod/alpine latest 961769676411 2 years 5.85 MB
Indicating 'ex.co/foo/bar' is a manifest list not a regular image, and so needs special handling by the user. Alternatively it could be it's own column. I was just wanted to be sensitive to anyone who may be scraping the space-separated data for some purpose.
What are your opinions/concerns/alternatives for something like this?
We should add the field to the end of list.
REPOSITORY TAG IMAGE ID CREATED SIZE TYPE docker.io/library/redis latest 7faaec683238 7 days 116 MB Image reg.fed.org/fedora 34 191682d67252 2 weeks 184 MB Image ex.co/foo/bar latest [M]123456576b54 1 second 123 GB List reg.acc.red.c/ubi8-init latest 670b0e87da3c 4 weeks 251 MB Image quay.io/libpod/alpine latest 961769676411 2 years 5.85 MB Image
I like that. For the sake of exploring an alternative: we could further separate *images* and *lists*. *podman-images* would only list images, and *podman-manifest-ls* (does not exist yet) would only list manifests.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 10/20/21 5:17 AM, Valentin Rothberg wrote:
For the sake of exploring an alternative: we could further separate /images/ and /lists/. /podman-images/ would only list images, and /podman-manifest-ls/ (does not exist yet) would only list manifests.
Given the oddball handling of `rm` and `push`, I like this idea better[*] than a new table-field. Requiring the user to go to `podman manifest ...` is a minor inconvenience for improved consistency. In other words, having to type `podman manifest ls` naturally encourages `podman manifest <whatever>`. This also keeps the table small (it already can grow quite wide) and removes any fear of breaking text-table output-scraping. [*] Note: There's an update in issue 11899 from Nalin indicating our oddball `rm` and `push` behavior may not actually have a precedent in "That Other Container Application". Making the CLI behavior uniform/unsurprising/boring is still my ultimate preference. -- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer My personal robot overlord told me to include this signature line.
On Wed, Oct 20, 2021 at 6:28 PM Chris Evich <cevich@redhat.com> wrote:
On 10/20/21 5:17 AM, Valentin Rothberg wrote:
For the sake of exploring an alternative: we could further separate /images/ and /lists/. /podman-images/ would only list images, and /podman-manifest-ls/ (does not exist yet) would only list manifests.
Given the oddball handling of `rm` and `push`, I like this idea better[*] than a new table-field. Requiring the user to go to `podman manifest ...` is a minor inconvenience for improved consistency. In other words, having to type `podman manifest ls` naturally encourages `podman manifest <whatever>`.
Dan, Nalin, what are your thoughts on separating images and manifests? It would be a breaking change and there are many things to consider for other commands (e.g,, push, tag) but we'd keep the oranges from the apples.
This also keeps the table small (it already can grow quite wide) and removes any fear of breaking text-table output-scraping.
[*] Note: There's an update in issue 11899 from Nalin indicating our oddball `rm` and `push` behavior may not actually have a precedent in "That Other Container Application". Making the CLI behavior uniform/unsurprising/boring is still my ultimate preference.
-- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer My personal robot overlord told me to include this signature line. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 10/21/21 5:57 AM, Valentin Rothberg wrote:
It would be a breaking change and there are many things to consider for other commands (e.g,, push, tag) but we'd keep the oranges from the apples.
Orange-colored apples no-less :S -- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer My personal robot overlord told me to include this signature line.
participants (3)
-
Chris Evich -
Daniel Walsh -
Valentin Rothberg