Skip to content
This repository was archived by the owner on Jan 11, 2023. It is now read-only.

bump k8s 1.6 release channel to version 1.6.9 #1343

Merged
merged 10 commits into from
Sep 1, 2017
Merged

bump k8s 1.6 release channel to version 1.6.9 #1343

merged 10 commits into from
Sep 1, 2017

Conversation

jackfrancis
Copy link
Member

@jackfrancis jackfrancis commented Aug 24, 2017

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 #1200

Release note:

Kubernetes v1.6.9 is the default 1.6 version for new clusters

This change is Reviewable

@seanknox
Copy link
Contributor

@jackfrancis v1.6.9 just came out, let's make that the default if you're ok with it.

@jackfrancis
Copy link
Member Author

@seanknox Do we have a windows tarball for 1.6.9?

@seanknox
Copy link
Contributor

I'll try building one now...paging @JiangtianLi in the likely chance I screw it up. :)

@jackfrancis jackfrancis changed the title bumped k8s 1.6 release channel to version 1.6.8 WIP - bump k8s 1.6 release channel to version 1.6.9 Aug 24, 2017
@jackfrancis
Copy link
Member Author

@seanknox Let me know when a v1.6.9intwinnat.zip artifact is ready and I'll kick off E2E, thanks!

@JiangtianLi
Copy link
Contributor

@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?

@seanknox
Copy link
Contributor

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.

@seanknox
Copy link
Contributor

@jackfrancis @JiangtianLi built and uploaded v1.6.9intwinnat.zip, just kicked off e2e.

JiangtianLi
JiangtianLi previously approved these changes Aug 24, 2017
Copy link
Contributor

@JiangtianLi JiangtianLi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@seanknox
Copy link
Contributor

Update: think the Windows zip should be good at this point, ran into caching issues with our CDN. Will revisit tomorrow.

@seanknox
Copy link
Contributor

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...

@seanknox
Copy link
Contributor

seanknox commented Aug 26, 2017

@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.

@JiangtianLi
Copy link
Contributor

@seanknox Do we have logs from e2e test?

@seanknox
Copy link
Contributor

@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.

@seanknox
Copy link
Contributor

seanknox commented Sep 1, 2017

Previous build succeeded, recent one failed due to what looks to be a transient Azure network error. Restarting.

++ kubectl exec win-webserver-1541187005-7ndp0 -- powershell iwr -UseBasicParsing -TimeoutSec 60 www.bing.com
++ grep StatusCode
iwr : The remote name could not be resolved: 'www.bing.com'
At line:1 char:1
+ iwr -UseBasicParsing -TimeoutSec 60 www.bing.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt 
   pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe 
   ll.Commands.InvokeWebRequestCommand


git cherry-pick 5fa0725025..232fa6e5bc
git cherry-pick 79cf9963f7..232fa6e5bc
Copy link
Contributor

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?

Copy link
Contributor

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).

Copy link
Contributor

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",
Copy link
Contributor

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.

Copy link
Contributor

@seanknox seanknox Sep 1, 2017

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

JiangtianLi
JiangtianLi previously approved these changes Sep 1, 2017
@jackfrancis jackfrancis merged commit 343774d into Azure:master Sep 1, 2017
@ghost ghost removed the in progress label Sep 1, 2017
@jackfrancis jackfrancis deleted the k8s-1.6.8-bump branch September 1, 2017 20:22
@seanknox
Copy link
Contributor

seanknox commented Sep 1, 2017

giphy 9

@jackfrancis jackfrancis changed the title WIP - bump k8s 1.6 release channel to version 1.6.9 bump k8s 1.6 release channel to version 1.6.9 Sep 1, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Kubernetes v1.6.9
4 participants