Use yaml file's parent as the working directory for podman kube play

[abalmos]

I was hoping to use podman kube play and the systemd [email protected] to replace existing docker-compose setups. Generally, we put all needed resources (config files, data volume mounts, etc.) into one folder. Then, with compose, one can refer to them using relative paths from the YAML file. As a result, the parent folder is somewhat portable--in the sense that one can move it and docker-compose up still does the right thing.

With podman kube play relative paths work, but they are relative to podman's current working directory, not the location of the yaml file being played. This renders [email protected] hard to use because the current working directory is not the parent folder of the yaml file being started. Therefore, all paths need to made absolute and now the "service folder" must know about where it lives on a particular machine.

Is it currently possible to make podman use the parent directory of the yaml as the current working directory? If not, perhaps that could at least be a cli flag, if not the default behavior?

[rhatdan]

@ygalblum @umohnani8 @haircommander WDYT?

[haircommander]

a flag makes sense to me

[ygalblum]

The request makes a lot of sense. In Quadlet for example, all relative paths are relative to the location of the .container or .kube files in order to allow the same portability that @abalmos referred to.
As for the CLI flag, just to make sure I understand, [email protected] will set this flag by default?

[umohnani8]

A flag makes sense to me as well - we will default to the current working directory of podman if this flag is not set. I will work on this next week.

[abalmos]

I suppose setting the flag in [email protected] is a breaking change, but one I personally feel would be worth it.

I'm not sure how podman handles breaking changes in terms of release cycle, but I hate to see the flag delayed because of [email protected]. In the meantime, the flag is enough to manually override [email protected].

[abalmos]

I feel like this should also apply to the Volume= directive of Quadlet too. Similar to EnvironmentFile=, Yaml=, and ConfigMap='s treatment.

[ygalblum]

I've opened a separate ticket #17418 to discuss this further

[Epokhe]

Any updates on this? I am using a custom .service file with WorkingDirectory set to yaml's parent folder to work around this. I would rather be able to use podman's systemd generator or quadlet.

[ygalblum]

@Epokhe While my name does appear in this discussion, I'm not sure why I separated parts of it to #17418 which was resolved already.

So, currently, Qualdet does support relative paths (relative to the location of the quadlet unit file). In addition, once #18830 is merged, you will be able to put the files of each unit in a separate directory.

Will this fulfill your requirements, or do you see further needs?

[Epokhe]

From my testing, I think quadlet supports relative locations for the configuration options it itself accepts, but it doesn't have an effect on the fields inside the kube yaml. Correct me if I'm wrong. In this case, it's a different thing than what I'm asking for.

File structure I and OP are talking about

project_folder
    kube.yaml
    app1_folder
        app1.conf

Inside kube.yaml, I want to be able to do

volumes:
    - hostPath:
        path: ./app1_folder/app1.conf
        type: File
      name: app1-config

and ./app1_folder/app1.conf gets resolved relative to kube.yaml.

[ygalblum]

Yes you are correct with your analysis. But, I don't think that this is a Quadlet specific issue, but a podman kube play one. IIUC Podman resolves the path relative to ${PWD}. For example, I ran podman kube play with the following YAML file:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: ./data
      # this field is optional
      type: DirectoryOrCreate

The directory data was created inside the directory I was, regardless to where the YAML file was.

So, in order to address this, I think we'll need a new flag to podman kube play overriding the base path it used to resolve relative paths.

@rhatdan @umohnani8 WDYT?

[rhatdan]

Should quadlet change the CWD of the executable to the location of the quadlet files, if the [session]
WorkingDirectory=/home/foo/scipts

Is not set?

[ygalblum]

As I wrote, I think this request should be handled at the level of podman kube play so that it addresses all sorts of use case, Quadlet being only one of them. Once supported, Quadlet can add a key to allow setting it either explicitly, or based on the location of the YAML file.

As for you question, not sure I know the WorkingDirectory configuration option. To what does it belong, systemd, podman, something else?

[fpoirotte]

WorkingDirectory is a systemd directive. From systemd.exec(5):

   WorkingDirectory=
      Takes a directory path relative to the service's root directory
      specified by RootDirectory=, or the special value "~". Sets the
      working directory for executed processes. If set to "~", the home
      directory of the user specified in User= is used. If not set,
      defaults to the root directory when systemd is running as a system
      instance and the respective user's home directory if run as user.
      If the setting is prefixed with the "-" character, a missing
      working directory is not considered fatal. If
      RootDirectory=/RootImage= is not set, then WorkingDirectory= is
      relative to the root of the system running the service manager.
      Note that setting this parameter might result in additional
      dependencies to be added to the unit (see above).

I think what @Epokhe asked for is exactly what rhatdan suggested: change the working directory to that of the quadlet file (when using quadlet) / YAML file (when using [email protected]) automatically, as if WorkingDirectory had been set to that directory explicitly.

I'm also +1 on having a way to make paths in the YAML file relative to that file. It makes for easier files to read/maintain and enables relocation.

[ygalblum]

@Epokhe @fpoirotte thanks for the discussion. Please see #19256

[ygalblum]

It seems that discussions are not resolved by PRs. So, I'm manually closing this issue