Create option to pass namespace as an option to helm

[ccapell]

helm has a flag -n, --namespace where the chart will be installed in the specified namespace. By specifying this as a CLI instead of inside the chart, you can create entire environments without a chart change. Use example

A DEV server where we want to create an environment for branch testing. We run the helm chart with the name of the branch and it can spin up a front end, back end, redis, DB, etc... Basically everything in a single namespace.

When no longer needed, delete the namespace.

[ConnorGraham]

You can set this in a bitops.config.yaml file https://bitovi.github.io/bitops/tool-configuration/configuration-helm/

[mickmcgrath13]

why as a command rather than the file? BitOps is centered around gitops patterns by putting everything in config files that we can.

@ConnorGraham said:

this was targeting a MR environment-like use case, but in most other circumstances, I agree with you.

for an MR env-like thing, you could introduce a new env variable to the docker run command like:

docker run \
-e MR_NAMESPACE="foo" \
... \
bitops:latest

..and then have a before script that modifies the bitops config env/helm/bitops.before-deploy.d/modify-namespace.sh

#!/bin/bash

bitops_config="$HELM_CHART_DIRECTORY/bitops.config.yaml"
# bash or yq magic to swap `namespace` in $bitops_config to be $MR_NAMESPACE

That would be my recommended approach as it follows the pattern of file-based functionality as much as possible by the time BitOps makes it to the env directory. One of the core functions of before scripts is to "convert" env variables to file stuff.

[mickmcgrath13]

fwiw, here's the logic that creates the namespace: https://github.com/bitovi/bitops/blob/master/scripts/helm/ensure-namespace-exists.sh

that logic could be easily updated to include a new parameter (though I still prefer the approach outlined in the previous comment).

The NAMESPACE env var in the ensure-namespace-exists.sh file comes from here: https://github.com/bitovi/bitops/blob/master/scripts/helm/helm_deploy_chart.sh#L71

..which is pulled from here: https://github.com/bitovi/bitops/blob/master/scripts/helm/helm_handle_chart.sh#L23-L25

[ConnorGraham]

..and then have a before script that modifies the bitops config env/helm/bitops.before-deploy.d/modify-namespace.sh

Unfortunately, bitops.config.yaml is processed before before any before scripts are run so it's too late to modify bitops.config.yaml https://github.com/bitovi/bitops/blob/master/scripts/helm/helm_handle_chart.sh#L22-L33

It would be nice to have an import_env or overriddeable property to the schema to essentially say if the export_env variable is already set, use it's value instead of what is defined in bitops.config.yaml https://github.com/bitovi/bitops/blob/master/scripts/helm/bitops.schema.yaml#L7-L11

This was we could do

docker run \
-e NAMESPACE="foo" \
... \
bitops:latest

and it would ignore what is in bitops.config.yaml's namespace: config

[mickmcgrath13]

ah, good point. totally overlooked that the bitops config gets processed before the before scripts. this would come in handy for that: https://github.com/bitovi/bitops/issues/58

I think the import_env or overrideable option is a good approach: https://github.com/bitovi/bitops/issues/137

In the meantime, this logic could be updated to something like:

local_namespace="$NAMESPACE"
if [ -n "NAMESPACE_OVERRIDE" ]; then
 echo "NAMESPACE_OVERRIDE set: $NAMESPACE_OVERRIDE"
  local_namespace="$NAMESPACE_OVERRIDE"
fi

if [ -n "$($k get namespaces | grep $local_namespace)" ]; then
    echo "The namespace $local_namespace exists. Skipping creation..."
else
    echo "The namespace $local_namespace does not exists. Creating..."
    $k create namespace $local_namespace
fi

fwiw: what we did for MR environments before was to have some prep scripts in the ops repo to clone a "template environment" (like _mr-env-template) and modify things like: bitops config namespace, urls in relevant helm charts by creating values-files/urls.yaml, etc.