(question) Deploy apps in ther own namespaces

[akaitux]

Overview

Allows to install modules (or rather their charts) in their own namespaces.

What this PR does / why we need it

By default, all helm applications are installed in one namespace. To install in a different namespace, you must specify it in each chart resource. Therefore, you cannot use external charts (through a dependency in Chart.yaml) whose resources do not contain fields with namespace. This code allows you to create a 'namespace' file in each module, in which you can specify its name (as you can now do in deckhouse in .namespace files) and the addon-operator will install the module in the specified namespace.

Special notes for your reviewer

Most likely this is not production code, since it was made in a day, not tested in production, and I am more of a devops engineer than a programmer. This pull request is more about whether this is a problem and whether this behavior will ever be implemented.

I needed to redo the basic logic of working with helm3 and helm3lib in terms of client initialization. By default, there is only one client and its settings were specified through the global options variable. I removed this global variable, and also remade the ClientFactory so that each module has its own client for its namespace (in the cache field). I also added arguments to create a namespace when creating helm release.

So far the only problem is the lack of namespace removal after module removal.

[diafour]

Therefore, you cannot use external charts (through a dependency in Chart.yaml) whose resources do not contain fields with namespace.

There is a bigger problem: you can't use hooks to prepare values for external charts (https://github.com/flant/addon-operator/issues/153). Adding namespace-per-module may fix only quite simple charts.

Please share, what are you trying to achieve with addon-operator and external charts?

[akaitux]

I would like to use third party charts and deploy them in their own namespaces. For example:

apiVersion: v1
name: openstack-cinder-csi
description: openstack-cinder-csi

version: 0.1.0

dependencies:
  - name: openstack-cinder-csi
    version: 2.28.1
    repository: https://kubernetes.github.io/cloud-provider-openstack

And build them in Dockerfile

    for i in $(ls -1 /modules); do \
        cd /modules/$i; \
        chmod +x enabled || true; \
        echo "Helm build for $(pwd)"; \
        helm dependency list $(pwd) 2> /dev/null | tail +2 | head -n -1 | awk '{ print "helm repo add " $1 " " $3 }' | while read cmd; do $cmd; done \
        && helm dependency build; \
    done

It cannot specify the namespace in which its resources should be installed by default. If you build an operator based on such charts, you end up with one large namespace with all applications, which is inconvenient. In deckhouse, as I understand it, this is solved with self-written charts.

[akaitux]

Fixed discovery of modules at startup through namespaces and secrets markings using labels in custom namespaces. Now non-existent modules are deleted at startup, although it seems that it would be worthwhile to additionally delete existing but disabled modules.

But there is no point in this, since it seems that to implement this functionality I had to rewrite a bunch of code and the project is simply not intended for this. It is unclear whether the hooks from the shell-operator were broken in this case. It’s not a fact that error-free tests guarantee backward compatibility for a deckhouse, and it most likely doesn’t need this feature at such a price.

This means we will try to use our own fork. For now we only need the function of deploying external charts without hooks.

Thanks for the feedback, I think the pull request can be closed.