-
Notifications
You must be signed in to change notification settings - Fork 222
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
Regarding release name #10
Comments
I see what you mean @vasusharma1 - how the canary version works right now is we build a new release for canary analysis and then when we want to release a production deployment we just remove this canary release. The canary release doesn't get promoted. This is mainly just because of some limitations with helm scripting. |
|
Ya there are some tricky pieces to get this working right, I've only tested
the workflow with the chart in this repository (at ./charts/app)
I explain the process in a blog post here:
https://deliverybot.dev/2019/09/14/safe-and-automation-friendly-canary-deployments-with-helm/
One of the key things with this style of canary deployments is that you
can't have conflicting resources in between your charts. With everything
working successfully you will have two helm releases:
- myapp
- myapp-canary
If any of the resources conflict between those releases, then it will fail
to deploy the canary. My guess is that when you are rolling out your canary
deployment you have conflicting resources. For example a Deployment
resource or Service resource have the same name.
To confirm this if you could post the helm chart that you are using and
some examples of Kubernetes manifests I could probably help more to debug
the problem.
…On Fri, Oct 4, 2019 at 6:36 AM Vasu Sharma ***@***.***> wrote:
1. I was actually deploying it, so i was unable to create in same
namespace it was giving me error of kube-dns already exists.
2. If i was doing it in different namespace but then it was giving me
already used port error.
3. Moreover, so say for example i am using "A" release in production,
so i will release canary version in same namespace or different namespace?,
after i come to know it is working fine then what will be my next course of
action?
Please, it will be great help to me if you can clarify all three
points technically.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10?email_source=notifications&email_token=ACR764IQDP3N4F2DEPC73GTQM5BEJA5CNFSM4I43CDJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALVGWI#issuecomment-538399577>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACR764MQCA34OM3YOAM6ZLTQM5BEJANCNFSM4I43CDJQ>
.
--
Colin Walker
colinwalker270@gmail.com | colinjfw.com | 778.709.1959
|
Sorry unfortunately i cannot share chart, but yes i think you are right name of my deployment is same because of which i might be having this issue. Let me try it once again after changing deployment name and following your post. I'll update status if i went into trouble in this thread and if everything works fine i'll close it. |
|
Hey sorry @vasusharma1 a bit late on this one. I think that different namespaces is up to you as long as the release name doesn't conflict. Overall I would probably go for the same namespace as that'll be easier to understand. |
thanks @colinjfw |
If we are changing release name as "A" to "A-canary" , then wouldn't it be less beneficial as our new release name will become "A" to "A-canary" ?
Please, clarify how to upgrade and during it change release name from "A" to "B"
The text was updated successfully, but these errors were encountered: