Closed johanneskastl closed 1 year ago
First, thanks for all the PRs. They do make the repo more usable which is great.
As for this change, have you tried this? The problem is that with this change you are creating a Podman Raw secret that is not meant to be consumed by pods created via podman kube play
. So, I'd rather not change the way the secret is created.
As for making it idempotent, I guess the way it to run podman secret list | grep <name>
and skip the creation step if it exists.
I'll also check if I can add an exists
command to podman secret
(similar to podman image exists
)
As for this change, have you tried this? The problem is that with this change you are creating a Podman Raw secret that is not meant to be consumed by pods created via
podman kube play
. So, I'd rather not change the way the secret is created. As for making it idempotent, I guess the way it to runpodman secret list | grep <name>
and skip the creation step if it exists.
Hmm, ok. Then I'll try to solve this another way. Would creating a YAML file and including it in quadlet-demo.kube work (like with the envoy configmap)?
Hmmm, while reading up on this I found that podman kube play
does not yet support secrets, according to the manpage.
https://docs.podman.io/en/latest/markdown/podman-kube-play.1.html
Currently, the supported Kubernetes kinds are: Pod Deployment PersistentVolumeClaim ConfigMap
I created the secret directly with kubectl ... -o yaml | podman kube play
command and got a podman secret, visible with podman secret ls
. So something is happening.
I used the code in this PR to successfully run the envoy proxy. However, something is fishy. The first start leads to a crashing envoy container. Stopping the service, removing the secret, re-creating it using the ansible code and restarting the container and the envoy container was running?
Also, creating the secret manually (kubectl ...) and then running Ansible did not try to touch the secret.
I'll have a closer look tomorrow, not sure what the issue was.
podman kube play
does support secrets. Thanks for letting me know it is not documented. I've opened a PR for it: https://github.com/containers/podman/pull/17866
And yes, podman kube play
disregards the command when trying to create a secret that already exists. The idea behind this decision was that secrets persist reboots while pods don't. So, if you have a YAML file with a secret and a pod, you can reuse it without having to first delete the secret. BTW the same goes for Volumes created via a K8S PersistentVolume.
As for your question about a way to add a reference to the secret in the .kube
file. No, currently podman kube play
does not have a way to add secret files. Keep in mind that the reason there is such a flag for ConfigMaps is that unlike Secrets, ConfigMaps are not saved in Podman.
Hi Ygal,
I had no time yet to debug why the podman secret did not work out of the box, but worked after a restart. But if podman kube play
just creates a podman secret out of the YAML from kubectl, then it should work, right?
However, I noticed that the mysql pod did not like the podman secret due to "no valid JSON/YAML". Again, I'll look into that later today or tomorrow.
@ygalblum Please tell me, if you want to keep the existing state and I should stop sending PRs. :-)
Replace shell task with containers.podman.podman_secret module to create the secret. Makes this idempotent (although still not working in check mode...)
The key details were slurped before into separate variables