Closed Ichmed closed 9 months ago
Ok, so we create a container in the current storage setup (which is usually an overlay of the container image and a space on the storage depending on the storage config). Next we mount that created container (podman mount) and bind mount an arbitrary host OS location into the container_mount_point/working_dir
then we start the container and give it an alternative working dir (normally /
) now set to /working_dir
. In /working_dir
we see data from the arbitrary host OS location.
My first question was: why ? what's the use case behind that, that cannot be solved by a --volume
setup ? why does it has to change the default working dir for calling the application ?
Maybe I'm missing a mechanism on how to do this without the changes.
Imagine you run a program inside of the flake that operates on your current working dir (like a python script for example), because the flake launches in "/" by default, the program will not be able to find the files.
Simply mounting "." into "/" may conflict with the setup of the flake so i mounted it "/working_dir". That requires the wd to be changed of course.
Imagine you run a program inside of the flake that operates on your current working dir (like a python script for example), because the flake launches in "/" by default, the program will not be able to find the files.
flake-ctl podman register --container ubdevtools --app /home/ms/ubuntu --target /bin/bash --opt "\--rm" --opt "\-ti" --opt "\--workdir /root"
---
include:
tar: ~
container:
name: ubdevtools
target_app_path: /bin/bash
host_app_path: /home/ms/ubuntu
base_container: ~
layers: ~
runtime:
runas: root
resume: false
attach: false
podman:
- "-ti"
- "--rm"
- "--workdir /root"
vm: ~
/root
Seems to work for me
Since @isbm decided to delete my access from this repository, it seems outside collaborators are no longer welcome. But I wanted to share my workdir
testing results with you, maybe it helps with this draft.
Thanks for your effort, you improved the code a lot
Maybe I'm missing something, but your version sets the working dir inside the container, yes, but it does not mount the current working directory of the HOST into the container, which is the whole point.
Maybe I'm missing something, but your version sets the working dir inside the container, yes, but it does not mount the current working directory of the HOST into the container, which is the whole point.
That can be done with a simple --volume host:guest
option. I still don't see a reason for additional code in the pilot to do this
You are completely right, this should be a more minimal implementation
Since @isbm decided to delete my access from this repository, it seems outside collaborators are no longer welcome.
This is actually absolutely not true. You have exactly the same rights as anyone of us has rights on your personal Kiwi project with precisely same level of "contributor welcomness". You always can offer your pull request exactly the same way as we can offer ours on Kiwi, and we always value your contributions.
Thanks.
Will be redone for new flake-ctl
Enables mounting the curretn working directory into the flake and lays some infrastructure for more complex mounting