Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[additionalimagestores] Allow global operations across all defined image stores #10394

Closed
srcshelton opened this issue May 18, 2021 · 4 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@srcshelton
Copy link
Contributor

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

It would also be useful to reconsider additionalimagestores as additional locations, rather than rigidly read-only locations.

So, for example, if podman image ls is used to view the unique IMAGE ID for an image in an additional image store, then podman image rm <ID> should remove the image linked to the specified ID (as the ID is unique) without having to specify --root and --storage-opt= options.

To ensure that this deletion is not performed by mistake, perhaps an extra argument could be required, such as:

podman image rm --all-stores <ID>

(… or --store=all, which could also allow a store to be selected by path, e.g. --store=/stoage/images).

See #9852 for context.

@openshift-ci openshift-ci bot added the kind/feature Categorizes issue or PR as related to a new feature. label May 18, 2021
@rhatdan
Copy link
Member

rhatdan commented May 19, 2021

I believe this is adding too much complexity and can easily be fixed, by fixing the --root options to allows users to simply interact with other stores.

@srcshelton
Copy link
Contributor Author

I'm kinda with you… for named images, having to specify --root to affect any secondary locations seems fine - button the same way it feels odd that when deleting by ID, a globally-unique identifier, an image visible from image ls can't be immediately removed.

I'll accept that the --store concept was perhaps taking things too far - but I'd still ask for consideration of being able to remove an image by ID if it is visible, regardless of the store it's in.

@rhatdan
Copy link
Member

rhatdan commented May 19, 2021

In my opinion, you don't know if the image is being shared with other users as well, so you really should know what you are doing before removing these images. One example might be that additional store is being shared with all rootless users on a system, or being shared over NFS to other systems or being shared inside of containers.
This was the idea when we were designing the system. Finally pluming this back into the storage layer would be very difficult, and I don't think there would be enough users to make it worth the effort.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan rhatdan closed this as completed Jul 9, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Development

No branches or pull requests

2 participants