dockerize kubernetes, helm, oc binaries

[remmeier]

instead of download the clients, they should be used through docker for better isolation, caching and platform-independence.

[iamahern]

So reading through this carefully I can see some gotchas for my teams usage of Helm. The are fixable, but you need to:

• propagate the KUBERNETES_CONFIG environment variable
• While propagating, manipulate the variable to refer to a mounted path within the container
• Mount the .yaml file referenced by the environment variable in the helm container

In the IBM Cloud integration, the .yaml file lives outside of the ${HOME}/.bluemix directory (for example).

---

I also can't decide if it is safer to duplicate some code and create dedicated/temporary HelmDocker plugin or HelmExec. With that approach, all existing functionality can remain stable while you deliver dangerous changes to a "HelmPluginNext" or HelmExecNext; it would just be hard to force users onto the new plugin.

As a compromise, I would do two things simple things:

• Tag the last v0.2 commit to allow patching
• Change this line in HelmExtension.java to maintain current behaviour while the plugin stabilizes; then change the default at a later stage. """ client.setDockerized(true); """

[remmeier]

tests can be duplicated to check old and new. In general things did not change. "Just" when doing the actual execution, there are those two different options how to execute it.

propagate the KUBERNETES_CONFIG environment variable

HelmExtension.setKubeConfig would do the volume mapping of the Kubernetes configuration and by default make use of a "private" one within the project and not the one of the user home.

0.2 tagging would for sure be fine. In general I would also like to move towards a 1.0 release that is considered to be feature complete/stable. 0.2 as the version suggests, is more of a first shot at it. For that purpose I will get feedback the coming weeks as well bout the current direction.

[remmeier]

a status update, current open topics:

• improved wrapper scripts to transparently do volume mappings
• "kubectl proxy" is one of the very few that needs a port mapping. Otherwise it should not be enabled because it may result in a conflict between multiple running instances.
• docker container are run in interfactive mode. Only necessary when accepting input (like piping something into it)
• "kubectl exec" needs to be checked, did not work on first try
• azLogin and azGetKubernetesCredentnials could be merged into one task
• on rate occasions have seen issues with volume mapping on Windows, needs to be checked what is up with that, whether there are any limitations.

in general still both dockerized/non-dockerized would be good to have. Question for the non-dockerized version would be how to get all the clients onto the users path in an easy fashion and whether there is any reasonable possiblity for isolation as in the docker case.