## Apps

This directory contains test applications which are using kustomize or
helm for testing. The objective of these apps is to create typical
flows for adding apps into clusters.

## Use case 1: common anchor

We want to achieve the following:

* have a common anchor to define the name of a service ("service1")
* That anchor steers generation of configuration files in config maps
  ("nginx config with hostname
  service1.$namespace.svc.$clusterdomain")

Best case: $clusterdomain can be queried from the cluster.

### kustomize

It does not seem kustomize has a logical way to support this, as it
does not have variables that can be injected into fields.

One can use the name-prefix or similar for modifying the service name,
but that prefix is not automatically injected into the relevant
configuration within a configmap.

### helm

Helm seems to cope with the anchor case easily using values.yaml as the
anchor.


## Handling of configmap updates

Assuming one updates a configmap (new configuration), what happens to
the old configmap? Is it left alone, is it deleted automatically?

### kustomize

Kustomize usually generates the ConfigMaps and appends a hash to its
name. Thus the referencing objects (Pods mostly) will also get updated
and refer to a new configmap.

Untested, but the assumption is that kustomize will leave the old
configmap behind.

### helm

Helm does not have a concept of generating confimaps, so in theory it
would update the same configmap (depending on how you named it).