Replies: 1 comment
-
Service creation and even moreso Ingress creation was deliberately eschewed because in most non-trivial scenarios, users need to customize these objects with annotations, ingress classes, route definitions, etc... This means you ultimately end up providing these options in the Rollout spec, and gradually duplicating the ingress/service spec in the Rollout spec. Therefore, it was decided to use a reference model for these objects, to allow those to be fully controlled by normal config management. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
It would be nice if argo-rollouts could take care of ingress and services creation/update.
If you look at how you need to deploy an application with rollouts, you end seeing a kustomize/helm scenario most of the time.
Inside the rollout CRD, there is enough data to compose an ingress > service > container resources and assuming 1:1 declaration of these resources in accordance with the existing K8s API wouldn't be too difficult to implement.
Example:
It shouldn't be a requirement to deploy the resources in this way, but as a nice to have ... IMHO, it looks useful and makes sense.
Looking for feedback/guidelines and probably I could be pushing a PR for this.
Regards
Beta Was this translation helpful? Give feedback.
All reactions