break helloWorld example into two examples:

- one for declaring a ConfigMap as resources
- one for declaring a ConfigMap from ConfigMapGenerator and rolling
update

examples/helloWorld/README.md

@@ -315,130 +315,3 @@ To deploy, pipe the above commands to kubectl apply:
 > kustomize build $OVERLAYS/production |\
 >    kubectl apply -f -
 > ```
-
-## Rolling updates
-
-### Review
-
-The _hello-world_ deployment running in this cluster is
-configured with data from a configMap.
-
-The deployment refers to this map by name:
-
-
-<!-- @showDeployment @test -->
-```
-grep -C 2 configMapKeyRef $DEMO_HOME/base/deployment.yaml
-```
-
-Changing the data held by a live configMap in a cluster
-is considered bad practice. Deployments have no means
-to know that the configMaps they refer to have
-changed, so such updates have no effect.
-
-The recommended way to change a deployment's
-configuration is to
-
- 1. create a new configMap with a new name,
- 1. patch the _deployment_, modifying the name value of
-    the appropriate `configMapKeyRef` field.
-
-This latter change initiates rolling update to the pods
-in the deployment.  The older configMap, when no longer
-referenced by any other resource, is eventually garbage
-collected.
-
-### How this works with kustomize
-
-The _staging_ [variant] here has a configMap [patch]:
-
-<!-- @showMapPatch @test -->
-```
-cat $OVERLAYS/staging/map.yaml
-```
-
-This patch is by definition a named but not necessarily
-complete resource spec intended to modify a complete
-resource spec.
-
-The resource it modifies is here:
-
-<!-- @showMapBase @test -->
-```
-cat $DEMO_HOME/base/configMap.yaml
-```
-
-For a patch to work, the names in the `metadata/name`
-fields must match.
-
-However, the name values specified in the file are
-_not_ what gets used in the cluster.  By design,
-kustomize modifies these names.  To see the names
-ultimately used in the cluster, just run kustomize:
-
-<!-- @grepStagingName @test -->
-```
-kustomize build $OVERLAYS/staging |\
-    grep -B 8 -A 1 staging-the-map
-```
-
-The configMap name is prefixed by _staging-_, per the
-`namePrefix` field in
-`$OVERLAYS/staging/kustomization.yaml`.
-
-The suffix to the configMap name is generated from a
-hash of the maps content - in this case the name suffix
-is _hhhhkfmgmk_:
-
-<!-- @grepStagingHash @test -->
-```
-kustomize build $OVERLAYS/staging | grep hhhhkfmgmk
-```
-
-Now modify the map patch, to change the greeting
-the server will use:
-
-<!-- @changeMap @test -->
-```
-sed -i 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
-```
-
-See the new greeting:
-
-```
-kustomize build $OVERLAYS/staging |\
-  grep -B 2 -A 3 kiwi
-```
-
-Run kustomize again to see the new configMap names:
-
-<!-- @grepStagingName @test -->
-```
-kustomize build $OVERLAYS/staging |\
-    grep -B 8 -A 1 staging-the-map
-```
-
-Confirm that the change in configMap content resulted
-in three new names ending in _khk45ktkd9_ - one in the
-configMap name itself, and two in the deployment that
-uses the map:
-
-<!-- @countHashes @test -->
-```
-test 3 == \
-  $(kustomize build $OVERLAYS/staging | grep khk45ktkd9 | wc -l); \
-  echo $?
-```
-
-Applying these resources to the cluster will result in
-a rolling update of the deployments pods, retargetting
-them from the _hhhhkfmgmk_ maps to the _khk45ktkd9_
-maps.  The system will later garbage collect the
-unused maps.
-
-## Rollback
-
-To rollback, one would undo whatever edits were made to
-the configuation in source control, then rerun kustomize
-on the reverted configuration and apply it to the
-cluster.