-
Notifications
You must be signed in to change notification settings - Fork 558
bump k8s 1.6 release channel to version 1.6.9 #1343
Conversation
@jackfrancis v1.6.9 just came out, let's make that the default if you're ok with it. |
@seanknox Do we have a windows tarball for |
I'll try building one now...paging @JiangtianLi in the likely chance I screw it up. :) |
@seanknox Let me know when a |
@seanknox Are you building 1.6.9 out of https://github.com/Azure/kubernetes/commits/release-1.6? I assume release-1.6 has 1.6.9 already? |
I'll be building from Azure/kubernetes, yes. We forked before v1.6.9 was released upstream; going to try rebasing our fork and will report back. |
@jackfrancis @JiangtianLi built and uploaded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Update: think the Windows zip should be good at this point, ran into caching issues with our CDN. Will revisit tomorrow. |
Windows VMs and K8s components appeared to come up, but looks like the Windows container deployment failed. I can look more tomorrow, @JiangtianLi would appreciate your help figuring this one out... |
@jackfrancis @JiangtianLi @jchauncey I'm stumped why Windows e2e keeps failing here. I manually tested a cluster from this branch using acs-engine; Windows containers start and outbound internet appears to work. |
@seanknox Do we have logs from e2e test? |
@JiangtianLi I canceled the build when I saw the failures which unfortunately doesn't save log artifacts (d'oh), kicked off e2e and will let it run all through this time. |
… picks For some reason, the first of our custom commits in release-1.6 (5fa0725025) was not being applied on our range of cherry-pick commits. Using the preceding commit fixes this for a reason still unclear to me.
Previous build succeeded, recent one failed due to what looks to be a transient Azure network error. Restarting.
|
|
||
git cherry-pick 5fa0725025..232fa6e5bc | ||
git cherry-pick 79cf9963f7..232fa6e5bc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to update k8s_17_cherry_pick too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, v1.7 cherry-pick is working fine (we merged another PR that bumped Windows to v1.7.5 today).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seanknox Did we push the build branch for v1.7? I didn't seem to find it although I found v1.6. If not, could we push v1.7 too, just to make sure we have all the commits in.
@@ -133,7 +133,7 @@ var KubeConfigs = map[string]map[string]string{ | |||
"dnsmasq": "k8s-dns-dnsmasq-amd64:1.13.0", | |||
"pause": "pause-amd64:3.0", | |||
"tiller": DefaultTillerImage, | |||
"windowszip": "v1.6.6intwinnat.zip", | |||
"windowszip": "v1.6.9-3intwinnat.zip", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should use v1.6.9-1 and not bump up since previous versions are just for experiment and not usable. There is no point to publish previous versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it really matters as they're internal artifacts and not referenced in any user documentation or code. Ultimately all we're declaring here is "use this specific zip artifact when provisioning Windows nodes." Plus, given the long turn around with CDN caching we want to feel able to change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this it doesn't matter what filename we use for this release. However, we should fix our process going forward where we test our way through this by referring to non-CDN experimental versions, and then only once we have a verified working artifact do we update to a CDN-consuming destination.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The caveat is that there is no good way to tell the difference between bad and good zip artifact from the cluster after it is deployed, and it would be hard for ACI team and us to root cause the issue if not from the zip version. But with CDN long delay, I agree this should not block us and we can improve next time.
What this PR does / why we need it: Upgrades default 1.6 version of kubernetes to
v1.6.9
.See: https://github.com/kubernetes/kubernetes/releases/tag/v1.6.9
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged): fixes #1200Release note:
This change is