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

[AlexGilleran]

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

[sajidanower23]

The official Kubernetes client for Javascript/Typescript has plenty of utility functions to interface with the Kubernetes Cluster.

Let's look at the scenario where we need to turn a deployment off and then on.

To delete a deployment, do this:

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const k8sBatchApi = kc.makeApiClient(k8s.BatchV1Api);
const k8sCoreApi = kc.makeApiClient(k8s.CoreV1Api);
const k8sAppsApi = kc.makeApiClient(k8s.AppsV1Api);

const NAMESPACE = 'default';

k8sCoreApi.listNamespacedPod(NAMESPACE).then((res) => {
    console.log("Pods: ");
    const pods = res.body.items;
    pods.forEach((pod, index) => {
        console.log(index + ': ' + pod.metadata.name);
    })
    k8sAppsApi.deleteNamespacedDeployment('storage-api', NAMESPACE).then((res) => {
        console.log('Deleted pod');
        console.log(res.body);
    })
    return res.body;
});

To create the deployment again, you can use the function createNamespacedDeployment, defined here.

You would need to create a V1Deployment object. The model is defined here.

I could not find any helm API that could change Kubernetes deployments. Here is an article that I looked at though.

[AlexGilleran]

Result of refinement discussion: Helm Operators still warrant further investigation (https://docs.fluxcd.io/projects/helm-operator/en/stable/helmrelease-guide/chart-sources/), because that might get us a solution that gets us everything we want. Next step is to dive deeper into helm operators and see if they'll do what we need and how complex that will make deployments.

[t83714]

Helm operator looks quite promising even without helm's three-way merge.

Our chart based fit this solution well if we make sure the following:

• Manual Setup/installation default should be moved from a separate values file to local deployment chart's value file
• Application's setting / runtime state is set via HelmRelease object 's value

In this way, we can have two layers of configuration:

• Local deployment chart config / values.yaml
• In cluster values files (as part of HelmRelease object)

The later actually works like helm's values file and can overwrite the former.

We still can upgrade to the newer version without losing a runtime setting.

[AlexGilleran]

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

[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 😄