Dashboard: Create new release

[maciaszczykm]

I am creating this issue to prepare for the new release :) It is going to be possibly the last release before Angular migration will be released. It's long time since the last one was done, so we need to test everything precisely. I hope that you will be able to help to test everything :)

Checklist

• [x] merge #3157
• [ ] metric API support (?)
• [x] verify that all required pull requests to the master are merged
• [x] tests on gulp serve:prod
• [x] tests on Docker image from our CI
• [x] release

In case of any suggestions, pull requests requiring review and merge please let us know here.

cc @kubernetes/dashboard-maintainers @pengx17 @austbot @jeefy @jimangel

[maciaszczykm]

Link to definition with HEAD image that should be used for test purposes: https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard-head.yaml

[jimangel]

/LGTM

I used the HEAD image above against a digital ocean dev cluster:

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:22:21Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Clicking around, I got stuck on Persistent Volumes and all links showed only that (after changing namespaces). I refreshed and haven't been able to recreate it.

When there is nothing to display, it links to "take the Dashboard tour" kubernetes docs - let's make sure those are up to date (maybe more important post migration).

Not sure if the "Dashboard Version" in the 'about' needs to be updated or if that is handled post release cut...

Clicking links seemed ok, was able to scale up/down deployments, tested exec'ing into pods, etc... Basic functionality seemed good!

Wasn't there some discussion about removing the skip button at the login prompt?

[jeefy]

I'll have more time mid-week to battle test things.

Do we have a list of all the PRs / features we want in before we cut a release? coughMetricsAPIcough The only one I know we were for-sure blocked on was godeps, but I'd like to confirm we're not missing anything else (and before we do a freeze/test of sorts)

Besides thoughts and testing, let me know what else I can do! :)

[maciaszczykm]

@jeefy Good! I have added metrics API to the todo list. It seems like really important feature right now. I am wondering how much effort is needed to implement it.

[floreks]

I will try to look into it soon.

[jimangel]

@maciaszczykm since we updated the client-go to 1.10, will this release be tagged as v1.10 and we won't have a 1.9 release?

[marceliwac]

There's a ticket for the metrics API (#2986) but it seems like there hasn't been much progress with it lately... Still though, worth adding it to the original issue description if anyone would want to have a crack at it! :octocat:

[floreks]

@jimangel Yes, we will do a 1.10 release. It is based on client-go support matrix for the core. Probably starting from new angular release we will jump to v2.0 and diverge a bit from the core versioning system.

[jeefy]

@maciaszczykm Two things:

1) I'd remove Metrics API for this release. It's going to take a fair amount of effort and planning to support it. (@floreks thanks for knocking me to my senses.)

2) Would it make sense to make a branch for the new release? We could then cherry-pick and release smaller dot-releases (if need be) prior to the Angular release.

[maciaszczykm]

I've tested it and it seems to work fine 👍 PR with new version number will be submitted soon. I will stick to K8s versioning, so it means that it will be v1.10.0.

[jeefy]

I've done my own testing locally and on a cluster at work and I've seen no issues at all either.

@maciaszczykm Once the PR is merged can we create a v1.10.x branch that we can keep around for a little bit post-ng-migration? (Or should that be a call topic?)

[maciaszczykm]

@jeefy We already have tags, isn't it enough?

[jeefy]

My thought was we might want to be able to (temporarily) support 1.10.x after the angular migration gets merged into master and _before_ (or even after) a 2.x release gets cut.

Certain things like bug and security fixes for backend could then be merged and a 1.10.x release could be cut from that branch while master progresses.

[floreks]

@jeefy That's a good idea. We should do that after 1.10 release.

[martinitus]

You might also want to update the compatibility matrix at https://github.com/kubernetes/dashboard/wiki/Compatibility-matrix after the release is finished;-)

Thanks for the great work guys and girls(?)!

[jimangel]

@aolsux will do, thanks.

[maciaszczykm]

We need to make sure/update version on core repo and minikube is up to date.

/reopen

[k8s-ci-robot]

@maciaszczykm: Reopening this issue.

In response to this:

We need to make sure/update version on core repo and minikube is up to date.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jeefy]

@maciaszczykm I have opened PRs in both k/k and minikube.

https://github.com/kubernetes/kubernetes/pull/68450

https://github.com/kubernetes/minikube/pull/3122

Let me know if I missed anything. I didn't think any deployment scripts really changed so I just iterated the version number. :)