-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow arbitrary secret names for certificates #18
Comments
From @krancour on October 6, 2016 16:28 This seems like a good idea. If I can propose how we'd do this... My thought is that the annotations on a routable service could reference a secret by name, and the router would use that, if specified. (This would work nicely for people using router without Workflow.) Otherwise, the router would look for the secret using the same naming convention as it does today. @gerred how does that compare to your own thoughts on this? |
From @krancour on October 6, 2016 16:55
Not sure what you mean. I'm imagining a new annotation on a routable service. The value of that annotation, if present, just references the secret by name. |
From @gerred on October 6, 2016 16:56 We're on the same page then. I wasn't sure if we were talking about having logic to try to "guess" based on the existing annotation. |
From @krancour on October 6, 2016 16:57 Nope. No guessing. |
From @gerred on October 6, 2016 15:6
https://github.com/PalmStoneGames/kube-cert-manager is opinionated in its secret name creation with its TPR, as is Deis in secret name usage for certificates. (append with -cert).
We should support any arbitrary secret name to make compatibility with other community tools easier.
Copied from original issue: deis/router#273
The text was updated successfully, but these errors were encountered: