Replace plugins with ksonnet files and lib.

[vmware-tanzu]

Replace plugins with ksonnet files and lib.

[timothysc]

It's fine be me however you want to break down the work. I figured there should be multiple PRs for this, and it's pretty thorny. I would probably start simple, and do a transformation 1st. We will need some means of getting meta-data(plugin type) out 1st, and I would probably start there. How do we load and get the meta-data to switch on type easily, without having to transform the whole thing.

FWIW, it's fine to have multiple PRs reference a single issue, just create a checklist and once the checklist is done, close the issue.

[timothysc]

@hausdorff @jessicayuen - Where should I log and track progress of a golang interface library.

https://github.com/ksonnet/ksonnet ?

[timothysc]

stretch goal would be to replace the plugin semantics.

[hausdorff]

@timothysc We've just transitioned ksonnet/ksonent to use go-jsonnet (rather than the cgo) language bindings, so I think we're ready to talk about this whenever you are.

[timothysc]

@chuckha this may flip in priority to overtake the interface library... sorry... I know, but there is good reason.

[chuckha]

I had a couple of thoughts on this ticket over the weekend:

This ticket is really trying to get at two things and I think we should break it up as such.

Formalize Plugin Spec

Right now a plugin is required to provide metadata (driver, resultType, etc) and provide a PodSpec. The driver implementation will use the appropriate Kubernetes resource (Pod/Daemonset) and use the provided PodSpec as well as create a ConfigMap with some metadata.

The plugin definition is not a valid Kubernetes resource, but it would be nice if it were. We can fit a plugin definition into the schema of Kubernetes resources, but we cannot know all the values until runtime. This suggest templating.

Work Proposal

Extract the parts of the Go that generate ConfigMaps, Pods & Daemonsets (from a plugin definition) and turn it into a Go template that gets evaluated at runtime. We should move the metadata information from the YAML into labels or annotations on the plugin Resources.

This will also require a bit of reshuffling of the plugin logic.

Ksonnet

The second part of this work is taking the template we create and using ksonnet to define the resources. We can replace the formalized templates we made above with ksonnet and evaluate the ksonnet to generate the Kubernetes resources at runtime.