-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Helm Operator for A/B deployment #4949
Comments
/cc @fabianvf |
Just putting this out there as something to consider. Do we want to expose this functionality in the I don't personally have a strong opinion, but one thing that comes to mind is the possibility of this being a footgun. I can foresee lots of issues, especially from users of an operator in the ilk of "why isn't my CR being reconciled?" and one of the first troubleshooting steps will be to look at the |
What about via an environment variable ? Similar to what you have for the namespace |
@joelanford wrt my PR (here), If no selector is specified in So if users don't specify any selector, which is the default, then everything remains the same. Do you still foresee a lot of issues? Correct me if I'm wrong anywhere. |
@VenkatRamaraju I think what @joelanford is saying is that |
I moved this to the backlog since it has |
@estroz Thanks for clearing that up. |
@estroz @joelanford I will say this currently is implemented in the Ansible's watches.yaml and we've not seen issues with it, I think it's primarily being used by teams that are both developing and deploying/managing the operator. I guess there is the potential for footgunning, but I also feel like it's a not uncommon pattern to scope reconciliation by label (I'm thinking specifically of ingress controllers here), and to rely on documentation of the controller to know what labels will lead to reconciliation. |
If this is already something ansible supports, then helm-operator can similarly adopt it imo. There seems to be extra parsing logic implemented for ansible's watches.yaml; @fabianvf is there a reason |
First thanks a lot for looking into this feature request, it will simplify my deployments. Is there an early release I could try or the implementation is still under discussion. Thanks ! |
Hi @jfgosselin, The feature has now been approved and merged onto master (#4997). It will be included in the next release of operator-sdk (1.11). It can also be used currently with the helm-operator binary built from the master, or the master tag for the helm-operator base image. |
Fixed by PR #5086 |
Feature Request
Describe the problem you need a feature to resolve.
I’m using the Helm Operator and I want to use it for an A/B deployment (or blue green/deployment) in the same namespace (it must be in the same namespace).
Obviously I can’t deploy two Helm Operators with the same watches.yaml but different Helm chart versions (they will step on each other).
I also don’t want to bump the CRD version for each new Helm chart release.
Describe the solution you'd like.
Each Helm Operator could watch the CR with a specific label defined in their watches.yaml e.g: release: A, release B.
Sorry, I think this feature was requested before but I can’t find the answer.
Thanks
JF
The text was updated successfully, but these errors were encountered: