You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It's a feature request, to prevent potential race condition problems.
The current implementation seems to be watching secrets in certain or all namespaces.
The problem is that a secret that is created might be attached to pods using environment variables (valueFrom: ...). But, at the time of being attached, the generator might not yet generate the required secret keys.
So there is a situation where a pod could be attached to a secret before the values are actually generated.
Describe the solution you'd like
By using a MutatingWebHook, the secret keys would be generated before the secret is available to pods.
The MutatingWebHook lifecycle will be triggered before the secret could be admitted, and it would prevent this race condition altogether.
Describe alternatives you've considered
Restart the pod if the key is not present on the secret
The text was updated successfully, but these errors were encountered:
There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.
Thanks for the suggestion, and 👍 from me on the general idea -- this would completely eliminate the (however short) period in which a required secret value would be missing and save us all the reconciliation loops.
However, since this is quite a major change, I cannot make any promises as to if and when we'd be getting to building this. As usual, any PRs in this matter are most welcome.
Is your feature request related to a problem? Please describe.
It's a feature request, to prevent potential race condition problems.
The current implementation seems to be watching secrets in certain or all namespaces.
The problem is that a secret that is created might be attached to pods using environment variables (valueFrom: ...). But, at the time of being attached, the generator might not yet generate the required secret keys.
So there is a situation where a pod could be attached to a secret before the values are actually generated.
Describe the solution you'd like
By using a MutatingWebHook, the secret keys would be generated before the secret is available to pods.
The MutatingWebHook lifecycle will be triggered before the secret could be admitted, and it would prevent this race condition altogether.
Describe alternatives you've considered
Restart the pod if the key is not present on the secret
The text was updated successfully, but these errors were encountered: