anchor.diff:  ----
   ====
   
  -We can also control the paths within the volume where ConfigMap keys are projected:
  +You can also control the paths within the volume where `*ConfigMap*` keys are
  +projected:
   
   ====
   [source,yaml]
  
positive.code: 
  toc::[]
  
  [[overview]]
  == Overview
  
  Many applications require configuration via some combination of config files, command line
  arguments, and environment variables.  These configuration artifacts should be decoupled from image
  content in order to keep containerized applications portable.  The ConfigMap API resource provides
  mechanisms to inject containers with configuration data while keeping containers agnostic of
  OpenShift.  ConfigMap can be used to store fine-grained information like individual properties or
  coarse-grained information like entire config files or JSON blobs.
  
  The ConfigMap API resource holds key-value pairs of configuration data that can be consumed in pods
  or used to store configuration data for system components such as controllers.  ConfigMap is similar
  to link:../dev_guide/secrets.html[secrets]), but designed to more conveniently support working with strings that do not
  contain sensitive information.
  
  Let's look at a made-up example:
  
  ====
  [source,yaml]
  ----
  
negative.code: Annotations:    <none>
  
  Data
  
  game.properties:        121 bytes
  ui.properties:          83 bytes
  ----
  ====
  
  You can see the two keys in the map are created from the file names in the
  directory specified in the command. Because the content of those keys may be
  large, the output of `oc describe` only shows the names of the keys and their
  sizes.
  
  If you want to see the values of the keys, you can `oc get` the object with the
  `-o` option:
  
  ====
  ----
  $ oc get configmaps game-config -o yaml
  
  apiVersion: v1
  data:
    game.properties: |-
  