From d9f82c9500754555ac256b7fa4adde251b1b7f65 Mon Sep 17 00:00:00 2001
From: Tim Bannister <tim@scalefactory.com>
Date: Tue, 23 Jun 2020 00:30:46 +0100
Subject: [PATCH] Explain ConfigMap volume source items array

The existing ConfigMap concept incorrectly states that you must use
different ConfigMap objects if you want to configure both environment
variables and file-like configuration items at the same time.

Reword to give the correct advice.
---
 .../docs/concepts/configuration/configmap.md  | 33 ++++++++++---------
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 1c1a24106e..c22c8f0312 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -126,25 +126,32 @@ spec:
       configMap:
         # Provide the name of the ConfigMap you want to mount.
         name: game-demo
+        # An array of keys from the ConfigMap to create as files
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
 ```
 
 
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.
 What matters is how Pods and other objects consume those values.
+
 For this example, defining a volume and mounting it inside the `demo`
-container as `/config` creates four files:
+container as `/config` creates two files,
+`/config/game.properties` and `/config/user-interface.properties`,
+even though there are four keys in the ConfigMap. This is because the Pod
+definition specifies an `items` array in the `volumes` section.
+If you omit the `items` array entirely, every key  in the ConfigMap becomes
+a file with the same name as the key, and you get 4 files.
 
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
+## Using ConfigMaps
 
-If you want to make sure that `/config` only contains files with a
-`.properties` extension, use two different ConfigMaps, and refer to both
-ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
-`player_initial_lives` and `ui_properties_file_name`. The second
-ConfigMap defines the files that the kubelet places into `/config`.
+ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
+parts of the system, without being directly exposed to the Pod. For example,
+ConfigMaps can hold data that other parts of the system should use for configuration.
 
 {{< note >}}
 The most common way to use ConfigMaps is to configure settings for
@@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
 adjust their behavior based on a ConfigMap.
 {{< /note >}}
 
-## Using ConfigMaps
-
-ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
-parts of the system, without being directly exposed to the Pod. For example,
-ConfigMaps can hold data that other parts of the system should use for configuration.
-
 ### Using ConfigMaps as files from a Pod
 
 To consume a ConfigMap in a volume in a Pod: