Spike: Make configuration able to be changed without a helm deploy

Description

Right now, most configuration that will be changeable in the new control panel is specified via values passed to helm. This means that when you want to change these values, you change the Helm values.yaml file and helm upgrade to make the changes to the installation.

However, the control panel wants to expose this to a user via a web UI with controls like this:

Obviously this is quite a ways from a command line. We need to figure out how to let a user make these changes from the UI and have them propagated across the whole system.

Things to address

• Some control panel values, like changing around what Add Dataset values are required, are a very simple matter of passing config into the UI - these could just as easily live in a database. However some of these could be quite complex - what do we do if the user enables/disables storage? Ideally we would disable the storage api entirely so it’s not taking up resources. How do we make that happen?
  • Can we use some kind of Helm API to make these changes? Seeing how this is equivalent to changing the values.yaml passed into helm, how would we make subsequent deployments on the command line if the values have been changed via the UI?
  • Should we use the K8S API directly, in a way that doesn’t break helm (similar to what the admin-api currently does to create new jobs)?
  • Could we shell out to helm and make it work that way?
  • Is this even practical at all? Maybe we should just have what config we can change sitting in a database or some other config store, and compromise on the bigger system changes like disabling/enabling APIs
• Once a change is made to the configuration, is it easy to continue deploying via the helm command line? How would this work (depending on the mechanism chosen this might be very easy or very hard)

Acceptance Criteria

• A plan for how to go forward (written as a response to this issue), addressing:
  • How we would make all of the changes that you can see in the Control Panel designs (https://projects.invisionapp.com/share/KTX7EW96FQV#/screens/424210194), or at least most of them if some are impossible
  • How we would address adding/removing connectors, minions etc, both as pods and as OpenFAAS functions (or maybe the solution is to move everything to openfaas?)
• Some kind of proof of concept for whatever mechanism has been chosen. i.e. if we want to go with changing Helm directly, we should have some kind of PoC that demonstrates changing a helm installation via our code, that still allows us to do command line deployments

[t83714]

@AlexGilleran That’s really cool~ it probaly allow us to have a mini version tiller running with HTTP API easily. I also think about picking up some GO lately 😄

[AlexGilleran]

Just saw this, might help: https://github.com/opskumu/helm-wrapper