Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/1c4d7fa9ee9e4f379796c7a77aaef7fd

• fi-ansible-lint-diff : SUCCESS in 5m 30s
• fi-yamllint-diff : SUCCESS in 3m 09s

This should be kept on hold. I might be able to store all configs in the roles and playbooks.

@kevin Is it possible to copy over templates through ansible in a newly created container? If not, then I would need this volume to store configurations.

You can copy templates... see the other apps using:

{% macro load_file(filename) %}{% include filename %}{%- endmacro -%}

...


data:
  config.toml: |-
    {{ load_file('config.toml') | indent }}

in deployment.yml... this loads config.toml in that openshift-apps/appname/tempaltes/config.toml

Or did you mean at a different level?

Or did you mean at a different level?

For example, I would like to turn database configuration into templates. So that staging and production have different hostnames and passwords. What is the correct way to do it? I am currently copying these files directly into the container, but that has to be changed.

You can use configmap (or secret if there are passwords in it) and use jinja template with some variable that you define in your playbook to customize the configuration file.
Something like this configmap.yml and then the actual config file can make use of jinja template variable, like this config.yml

Then you mount that config file on your deployment like this:

    spec:
      containers:
        volumeMounts:
        - mountPath: /usr/lib/python3.9/site-packages/osh/hub
          name: hubconfigdir
        - mountPath: /usr/lib/python3.9/site-packages/osh/hub/settings_local.py
          name: hubsecretfile
          subPath: settings_local.py
...
      volumes:
      - name: hubconfigdir
        configMap:
          name: myconfigmap
      - name: hubsecretfile
        secret:
          secretName: mysecretconfig

The first syntax (hubconfigdir) is the default, and mount your secret/configmap content on top of the mount path. Any existing files that live here become inaccessible. Just like a regular mount.

The second syntax (hubsecretfile) mount only the file of your secret/configmap specified by the subPath field. Any existing files in the target directory remain intact.
The downside of this syntax is if you change the content of your configmap/secret, the pod needs a restart to see the changes.

As you can see the usage of secret and configmap here is pretty much the same, up to you to choose the right one. But I recommend a secret if you want to store anything.... well, secret :)

Is this PR still needed?

Is this PR still needed?

No.