Hello,
We deploy secrets independently from our applications because multiple applications consume the same shared secrets. Currently, we configure spec.rolloutRestartTargets by explicitly listing the names of dependent Deployments.
While this works, it creates tight coupling between the secret configuration and specific deployment names. It would be more flexible and scalable if rolloutRestartTargets could also be defined using Kubernetes label selectors instead of explicit resource names.
Using labels would allow each application’s deployment.yml to control both:
1. Its dependency on specific secrets.
2. And whether it should be included as a rollout restart target when those secrets change.
Example..
spec:
rolloutRestartTargets:
matchLabels:
restart-on-dbSecrets-change: "true"
And the application deployment would have a label defined as follows:
metadata:
labels:
restart-on-dbSecrets-change: "true"
Hello,
We deploy secrets independently from our applications because multiple applications consume the same shared secrets. Currently, we configure spec.rolloutRestartTargets by explicitly listing the names of dependent Deployments.
While this works, it creates tight coupling between the secret configuration and specific deployment names. It would be more flexible and scalable if rolloutRestartTargets could also be defined using Kubernetes label selectors instead of explicit resource names.
Using labels would allow each application’s deployment.yml to control both:
1. Its dependency on specific secrets.
2. And whether it should be included as a rollout restart target when those secrets change.
Example..
spec:
rolloutRestartTargets:
matchLabels:
restart-on-dbSecrets-change: "true"
And the application deployment would have a label defined as follows:
metadata:
labels:
restart-on-dbSecrets-change: "true"