podman_container: using YAML dictionaries for options in the secrets parameter

[ivanov17]

/kind feature

Description

Hello, Sergey! What do you think about using list (or dictionary) of dictionaries in addition to using a list of strings for the secrets parameter in the containers.podman.podman_container module?

It might look like this:

- containers.podman.podman_container:
    ...
    secrets:
      - secret: my_file
        type: mount
        target: /run/secrets/file.txt
        uid: 101
        mode: 0600
      - secret: my_variable
        type: env
        target: MY_VARIABLE
    ...

Or like this:

- containers.podman.podman_container:
    ...
    secrets:
      my_file:
        type: mount
        target: /run/secrets/file.txt
        uid: 101
        mode: 0600
      my_variable:
        type: env
        target: MY_VARIABLE
    ...

It seems to be a little more readable than this:

- containers.podman.podman_container:
    ...
    secrets:
      - "my_file,type=mount,target=/run/secrets/file.txt,uid=101,mode=0600"
      - "my_variable,type=env,target=MY_VARIABLE"
    ...

Also, if multiple Jinja variables are used in a string, it becomes too long.

[sshnaidm]

It's doable of course, but it will be backward incompatible, which will break current users of podman_container. I would consider it for next version 2 of collection, which will be anyway incompatible with version 1.

[ivanov17]

Can we to have two syntax variants at the same time: list (or dictionary) of dictionaries and list of strings? I think the module could check the type and just concatenate keys and values into a string if it's a dictionary.

In any case, there is nothing critical here. It's just an idea to make working with secret options a little more convenient. Thank you.

[sshnaidm]

It's possible to add another variable like secrets_dict or something similar, module has strict type for each variable. But in this case we'll need to handle idempotency for one parameter from two different variables, which will be non trivial. I think better to plan it for next version.

[ivanov17]

module has strict type for each variable

Now it's clear, thank you. Yes, this is really worth doing in the next major version.