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

[RFE] podman volume mount|unmount command #12768

Closed
mskarbek opened this issue Jan 7, 2022 · 14 comments · Fixed by #13318
Closed

[RFE] podman volume mount|unmount command #12768

mskarbek opened this issue Jan 7, 2022 · 14 comments · Fixed by #13318
Labels
Good First Issue This issue would be a good issue for a first time contributor to undertake. 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.

Comments

@mskarbek
Copy link

mskarbek commented Jan 7, 2022

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

/kind feature

Description

I would like to be able to mount a volume independently of the container.
Use case: creation of a volume that is then mounted and populated with autogenerated config files before it is attached to the newly created container.
Yes, I know that I can just create directory, put config files there and just use -v or tar content of that directory and volume import it.
The above is a convenience request that will simplify a little dealing with volumes (skipping tar steps) and allow keeping everything as a programmatically declared volume without tracking separately random directories populated outside the podman volume functionality.

@openshift-ci openshift-ci bot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 7, 2022
@flouthoc
Copy link
Collaborator

flouthoc commented Jan 7, 2022

@mskarbek Thanks for creating the issues.

If i got the issue correctly.

Could we use volume with type=bind ? #12687
It should allow bind mount of arbitrary location from host as a podman volume

@rhatdan
Copy link
Member

rhatdan commented Jan 7, 2022

Do you want podman volume mount NAME destination?

@rhatdan
Copy link
Member

rhatdan commented Jan 7, 2022

Or would
$mntpnt=$(podman volume mount NAME)
$podman volume umount NAME

Be enough?

@mskarbek
Copy link
Author

mskarbek commented Jan 7, 2022

@rhatdan this can behave the same way as podman mount/buildah mount so $mntpnt=$(podman volume mount NAME) will be ok.

@rhatdan
Copy link
Member

rhatdan commented Jan 7, 2022

I am fine with adding it. Interested in opening a PR?

@flouthoc
Copy link
Collaborator

flouthoc commented Jan 7, 2022

@mskarbek @rhatdan
I might be missing something but all the volumes should be already accessible by host. Especially if driver is local and for any other driver src of mountpoint must be accessible from host first.

So if you do podman volume inspect $myvol we should able to see the mountpoint.

If only mountpoint is needed this should be pretty enough right ?

$ podman volume inspect myvol | jq '.[0].Mountpoint'

Again i might be interpreting the issue wrongly. But this is what I remember while discussing something with @mheon in past over an older PR.

@mskarbek
Copy link
Author

mskarbek commented Jan 7, 2022

@flouthoc your logic is sound when it comes to the plain local volumes, I don't need to mount them, they are just directories, but:

podman volume inspect eb712af1-acfa-4eb7-9c99-3ab3e5777d9c
[
    {
        "Name": "eb712af1-acfa-4eb7-9c99-3ab3e5777d9c",
        "Driver": "local",
        "Mountpoint": "/var/lib/volumes/storage/eb712af1-acfa-4eb7-9c99-3ab3e5777d9c/_data",
        "CreatedAt": "2021-12-20T22:11:38.745502358+01:00",
        "Labels": {},
        "Scope": "local",
        "Options": {
            "device": "dfe93b5a-632d-44c4-98b9-7cff969b3a1d/datafs/var/lib/volumes/storage/eb712af1-acfa-4eb7-9c99-3ab3e5777d9c",
            "type": "zfs"
        }
    }
]

This is a ZFS dataset with mountpoint=legacy declared as a volume in podman. Such dataset will be mounted during container start, the content of that file system is not always available under "Mountpoint": "/var/lib/volumes/storage/eb712af1-acfa-4eb7-9c99-3ab3e5777d9c/_data".
Yes, I can automate everything, but the issue is about keeping user experience as podman-focused as possible.
Besides of test/prod envs we use VMs for our developers with RHEL 8 prebuild image with ZFS - ZFS is an important part providing snapshots and send/receive functionality for datasets that are used on developers VMs, it's a convenient way of shipping test database content for example.
Those VMs are partially automated with Ansible, but developers need normal access to them, and they interact with podman daily. It would be much easier for them to not think about looking for datasets, mounting them, unmounting, but to keep everything nice and tidy under one coherent podman experience. They are familiar with podman mount functionality, so replicating that experience under podman volume mount essentially masking the underlying storage backend would be appreciated.
As I previously stated it is a convenience request not a dealbreaker. ;)

@flouthoc
Copy link
Collaborator

flouthoc commented Jan 7, 2022

@mskarbek Ah fair got it. You want mounting experience to be more podman oriented. That's a fair request.

@rhatdan
Copy link
Member

rhatdan commented Jan 7, 2022

@flouthoc Yes,certain non local file systems are mounted (tmpfs, bind, nfs, and fancy docker-volume-plugins) could be mounted.

Currently when you run a container for the first time with a volume podman mounts the volume in container/storage then setup a bind mount into the container. @mskarbek is looking to only do step 1, where we do the mount. All of the code is there to do this, but someone needs to implement the CLI and then call into the functions to make it happen.

CLI should only be local, not remote API.

@rhatdan rhatdan added the Good First Issue This issue would be a good issue for a first time contributor to undertake. label Jan 7, 2022
@boaz0
Copy link
Collaborator

boaz0 commented Jan 11, 2022

@rhatdan can I work on this?

@rhatdan
Copy link
Member

rhatdan commented Jan 11, 2022

Yup

@github-actions
Copy link

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

@rhatdan
Copy link
Member

rhatdan commented Feb 11, 2022

@boaz0 any progress?

@boaz0
Copy link
Collaborator

boaz0 commented Feb 15, 2022

@rhatdan - sorry but I won't be able to work on it. Feel free to reassign this to someone else.
Thanks.

rhatdan added a commit to rhatdan/podman that referenced this issue Feb 28, 2022
Fixes: containers#12768

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@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 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Good First Issue This issue would be a good issue for a first time contributor to undertake. 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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants