Control dynamic kubectl download about kubernetes-mixin

[vdice]

This looks good to me.

minor - The Major.Minor versions do not match. The patch version is allowed to be different.

Should be minor - The Major.Minor versions match. The patch version is allowed to be different., right?

My only other thought is to think about if this will prove to be generically useful across mixins enough to consider placing somewhere in a/the main Porter repo such that it's inherited by any basic mixin implementation (maybe clientVersion could be included at the same time). However, it doesn't quite fit in exec's builder pkg, where we've previously placed similar interfaces... so this would probably be a separate/broader design/discussion.

[carolynvs]

Oh we can tweak the wording. The sentence above was "A download is triggered when: ..." so the condition for triggering a download is when the Major.Minor doesn't match. But we can flip it to talk about matching instead, whatever is less confusing.

Some of the logic we are discussing here is specific to kubectl (such as the backwards compatibility) so we would want to use interfaces again like we have in the builder package to opt into various behaviors. So yeah I think it would work well to be a common package in porter. We can find a spot for it, maybe a subpackage under pkg/mixins/FEATURE would be a way to do it going forward. But that can be worked out in an issue in the Porter repo.

[MChorfa]

I really love the idea of configurable dynamic download and the adaptation of this feature to other mixins. Moreover, it could resolve this question about downloading user-defined mixins see: getporter/porter#975
I wonder when the download would happen. Is it at build-time or later at runtime? as a universal behavior

[carolynvs]

I'm glad you are interested in this path!

The dynamic installation of the kubectl client must occur at bundle execution. This is because it relies upon credentials to connect to the user's (not bundle author's) cluster to identity the targeted cluster version. Every time the bundle runs, it can be used against a different cluster with a different version of Kubernetes.

The mixin configuration allows the bundle author to specify the default kubectl client version that should be installed at buildtime. When it is not specified, it will fall back and install the version hard coded in the mixin. We can also improve the mixin to always install the latest version of kubectl which I think would be a welcome change.

This gives us a minimum of one and possibly two downloads. There is always a download that occurs at buildtime which guarantees that there will always be a kubectl client in the invocation image. This client may then be optionally used to detect the cluster version at runtime and then download a matching version dynamically.

---

For the other issue you referenced, getporter/porter#975, mixin installation always occurs at buildtime. Mixins are built into bundle during porter build and never needed to be installed on the client in order to execute a bundle (runtime). If you'd like to chat about that issue further, let's do it on that issue so that we keep the discussion in one place.