Bootstrapper should optionally use config map to specify ksonnet parameters

[jlewi]

I propose the bootstrapper optionally take a YAML file that looks like the following

app:
  component:
     - name: (of component)
       prototype: Name of prototype to install
  packages:
     - name: (Of package to install)
  parameters:
     - component: name of component
       name: (name of parameter)
       value: (value of parameter)

The idea of passing parameters to the bootstrapper using a config map was first suggested by @inc0 . There were a couple questions about how to do this in particular

1. Not creating yet another templating / config layer around ksonnet
1. Exposing all parameters consistently and not selectively

It might be nice if this functionality was incorporated directly into ks so that one could do something like

ks init my-app --config=myconfig.yaml

Motivation:

We'd like the bootstrapper to be useable by Kubernetes deployment tools. Examples that are already integrating with Kubeflow

• Canonical Jujuj
• GCP Deployment Manager

These upstream tools can be responsible for

1. Provisioning the K8s cluster and non K8s resources
2. Creating K8s resources needed to run the bootstrapper (e.g. cluster role bindings)
3. Triggering the bootstrapper

The advantage of this approach is that all K8s manifests (even vendor specific ones) can be managed consistently as part of the Kubeflow ksonnet app. vendors can add packages, prototypes, and/ parameters specific to their distribution and then just enable them via the config map.

/priority p1
/cc @bryanl @inc0 @kunmingg @carmine @marcoceppi

[kunmingg]

/assign kunmingg

[kunmingg]

/close