++readme for apps

apps/README.md

@@ -0,0 +1,50 @@
+## 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).