Unclear which directory to be in when running "godep-restore" during updating_kubernetes.md guide

[erulabs]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Please provide the following details:

Environment:

Minikube version (use minikube version): 0.22.2 (also present on master at time of posting)

• OS (e.g. from /etc/os-release): MacOS
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyve (but not applicable, issue is a documention one)
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): 0.22.2
• Install tools:
• Others:

What happened:
In https://github.com/kubernetes/minikube/blob/c1c4455c0f1fc0f2a73eb6273cf46dc83996d22e/docs/contributors/updating_kubernetes.md after running git checkout $DESIREDTAG, I expected the godep-restore.sh script to be located at ./hack/godeps/godep-restore.sh, but it was in fact located at ./hack/godep-restore.sh

(commit targeted is current master at time-of-posting)

What you expected to happen:
The documentation should match the actual file paths :)

How to reproduce it (as minimally and precisely as possible):
Just follow the guide: https://github.com/kubernetes/minikube/blob/c1c4455c0f1fc0f2a73eb6273cf46dc83996d22e/docs/contributors/updating_kubernetes.md

(commit targeted is current master at time-of-posting)

Anything else do we need to know:

The contributing guidelines appeared to encourage an issue, rather than a PR. In any case, I have prepped a branch here: https://github.com/erulabs/minikube/tree/patch-1

Also, I'd be happy to go ahead and move minikubes hack/godeps scripts "up one level", so as to match kubernetes/kubernetes

Let me know - and thanks for all the work on k8s!

[r2d4]

I don't see any file at ./hack/godep-restore.sh, but it looks like its in the right place? https://github.com/kubernetes/minikube/blob/master/hack/godeps/godep-restore.sh

[erulabs]

@r2d4 Ah, perhaps I understood the instructions incorrectly? The docs say:

cd $GOPATH/src/k8s.io/kubernetes
git fetch --tags
...
git checkout $DESIREDTAG
./hack/godeps/godep-restore.sh

I was assuming the final ./hack/godeps/godep-restore.sh was run in the Kubernetes directory? If not, maybe we can add a cd $GOPATH/src/k8s.io/minikube (like in step 5 of that guide) - since it's not clear when we're in the kube or the minikube directories.

Since we're changing to a different branch of kubernetes, it seems reasonable to want to run their godep-restore script? Which is located in ./hack/godep-restore.sh, not ./hack/godeps/godep-restore.sh

Edit: working thru this right now, and starting to understand. Godeps will locate the kubernetes repo I've checked out and install its deps, because kubernetes is a dep of minikube. So, the correct edit here is to add an instruction to change back to minikube directory after checking out the desired kube version (ie: adding cd $GOPATH/src/k8s.io/minikube to the end of "step 4" (sorry, I am not a Go developer, but a sysadmin trying to play with a new feature in Kube 1.8)

[erulabs]

Updated title to reflect what I've learned :)

[erulabs]

Ack! Running ./hack/godeps/godep-restore.sh in minikube seems to revert my gopath/src/k8s.io/kubernetes to master (or at least, downgrades me to 1.7.5 from 1.8.0). So that guide is for sure not correct currently.

I'll spent a bit more time on this and come back with a more useful report 👍

[r2d4]

the godep-restore.sh script will parse the Godeps/Godeps.json file which has a list of dependencies of minikube and the version that we are currently pinned to. So, it will fetch those packages and checkout our pinned version in your GOPATH.

the godep-save.sh script will take whatever is currently in your GOPATH and update our pinned dependencies with them.

If you're trying to 'update kubernetes', you can run the https://github.com/kubernetes/minikube/blob/master/hack/godeps/godep-update-k8s.sh script with KUBE_VERSION=

(the guide should probably be updated to say that)

the godep-update-k8s script basically does

1. godep-restore to make sure all of your packages are at the same versions as we are pinning to
2. make some changes, such as checking out a different version of kubernetes or updating some other package
3. godep-save script which updates our dependencies and sticks the package in our vendor directory.

[erulabs]

@r2d4 wonderful, KUBE_VERSION=v1.8.0-beta.1 ./hack/godeps/godep-update-k8s.sh is exactly what Im looking for. Would you appreciate a PR to update that guide a bit (assuming I get a build of 1.8 actually working properly xD)?

Thanks again!

[r2d4]

@erulabs absolutely. Usually we track the upcoming release in a different v1.8 branch, but we haven't created that branch yet. We would appreciate a PR

[erulabs]

Hrm, seems like some breaking dep issues with upgrading to Kube 1.8 that are non-trivial... Can't get minikube to build after upgrading to 1.8 :<

Unfortunately, I may be about blocked on this as-is - my application requires "mount propagation", which is both not available in kube 1.7.5 and appears to crash minikube's (rather old) docker service when run manually (outside kubelet). My rather timeboxed exploration has unfortunately come to an end.

I believe you're exactly right about ./hack/godeps/godep-update-k8s.sh, but 1.8 must not be a "normal" upgrade heh.

Will keep my eyes glued here for a minikube with a new docker and kube 1.8!

Thanks for all the help / hard work and sorry for the distraction! 👍

[r2d4]

@erulabs once #1985 is in, you'll be able to run 1.8.0-beta.0 with

minikube start --kubernetes-version=v1.8.0-beta.0 --bootstrapper=kubeadm