Skip to content
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

Canary Deployment patterns (spike) #40

Open
evanlouie opened this issue Feb 12, 2019 · 5 comments
Open

Canary Deployment patterns (spike) #40

evanlouie opened this issue Feb 12, 2019 · 5 comments

Comments

@evanlouie
Copy link
Collaborator

evanlouie commented Feb 12, 2019

As an operator, I want best practices on how to do A/B testing and canary testing within the context of Istio.

AC: documentation and guidance on how to properly do canary testing for multiple services within the mesh.

@evanlouie
Copy link
Collaborator Author

@bnookala
Copy link
Member

bnookala commented Feb 25, 2019

Question raised by @dtzar: will istioctl be a hard requirement for applying istio virtualservice rule updates?

Also to investigate: azure devops plugin for gated rollouts based on monitoring and metrics gathered from prometheus/grafana

@andrebriggs - This will impact how your team deploys and configures flux/azure devops for multiple clusters.

@andrebriggs
Copy link
Collaborator

andrebriggs commented Feb 26, 2019

Question raised by @dtzar: will istioctl be a hard requirement for applying istio virtualservice rule updates?

@bnookala I'm not sure why it would be a hard requirement. Can't we achieve canary deployments with only kubectl apply? Seems to fit the current flux-enabled cluster deploy strategy right now.

Also to investigate: azure devops plugin for gated rollouts based on monitoring and metrics gathered from prometheus/grafana

The above sounds like a separate issue. We have various meeting notes on the strategy able being alluded to.

@andrebriggs - This will impact how your team deploys and configures flux/azure devops for multiple clusters.

Agreed. This scenario is a "run" stage scenario as opposed to the current "crawl" and "walk" scenarios

@evanlouie
Copy link
Collaborator Author

No requirement specifies the use of istioctl. In fact, if possible, I would stay away from istioctl. I think it should be manageable for most operators to manage even complex routing rules with manifests alone.

@dtzar
Copy link
Collaborator

dtzar commented Feb 26, 2019

yes @andrebriggs I agree it should be a separate task. I created this one: #45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants