kubectl is hardcoded to v1.7.4

[MHBauer]

https://github.com/IBM/container-service-getting-started-wt/tree/master/Lab%200#download-the-kubernetes-cli

suggested remedy is to link directly to kubectl documentation
https://kubernetes.io/docs/tasks/tools/install-kubectl/
or otherwise set up a checklist for review

On new kubernetes release:

• kubectl version update

[jkomg]

The reason we did this was because we'd cut a release for the class. The intent was to update & cut for each additional release we did, so the learning material itself (hosting on dW) wouldn't be broken by changes upstream.

I'm willing to discuss making it a living document, though, if it won't break earlier releases of the course.

[bhpratt]

I know the docs originally did this (hardcode to 1.5) when we were so far behind the current Kubernetes release. It might be worth simply link to K8s now that we're pretty close.

At minimum we should update the current links to 1.8 kubectl since 1.8 is the default version of K8s for ICCS.

[jkomg]

I'm down with this. So we're saying hardcode to 1.8?

[jkomg]

@vwilburn what are your thoughts here?

[kKronstainBrown]

@jkomg, @vwilburn asked me to share how the doc team manages this kind of thing. Not sure it will help you our directly, but maybe spark some ideas for how you could manage this information.

While we were trying to figure out how to concisely manage one set of documentation across a GHE (staging) and a GH (prod) repo, we implemented a script to help us out. We write docs in a source repo in GHE, then a python script runs and pushes the staging/prod tagged content to the correct staging/prod repo. While we were implementing that, we also included in the script the ability to handle custom variables. We have a variable for the current Kubernetes version that we can update in one place and when the files get pushed to staging and prod, the variables are replaced with the correct values in all the places they're used. It's a very customized solution specifically for the docs framework, but you could always do something similar between branches in the same repo rather than across different repositories, if you wanted to try and single-source a value like that.

However, there are still manual elements to the Kube version process for us as well. We still have version specific docs related to upgrading workers nodes that we maintain by reviewing info in Kubernetes change logs. The versions used there can't really be automated. We rely on the dev squads to tell us when a new version of Kube is being supported so we can make sure we have the right information before customers figure it out first.

Hope this helps!

[bhpratt]

closing