anchor.diff:                fieldPath: metadata.annotations
     restartPolicy: Never
   ----
  +====
   
   . Create the pod from the `*_volume-pod.json_*` file:
  -
  ++
   ====
   ----
   $ oc create -f volume-pod.json
   ----
   ====
   
  -. Check the container's logs with:
  -
  +. Check the container's logs and verify the presence of the configured fields:
  ++
   ====
   ----
   $ oc logs -p dapi-volume-test-pod
  
positive.code: 
  == Overview
  
  It is common for containers to consume information about API objects.  The downward API is a
  mechanism that allows containers to do this without coupling to OpenShift.  Containers can consume
  information from the downward API via environment variables or a volume plugin.
  
  == Selecting fields
  
  Fields within the pod are selected using the `FieldRef` API type.  `FieldRef` has two fields:
  
  <1> `fieldPath`: The path of the field to select, relative to the pod
  <2> `apiVersion`:  The api version to intepret the fieldPath selector within
  
  Currently, there are four valid selectors in the `v1` API:
  
  <1> `metadata.name`: the pod's name
  <2> `metadata.namespace`: the pod's namespace
  <3> `metadata.labels`: the pod's labels
  <4> `metadata.annotations`: the pod's annotations
  
  The `apiVersion` field, if not specified, defaults to the API version of the enclosing pod
  template.
  
  In the future more information, such as resource limits for pods and information about services,
  will be available via the downward API.
  
  == Consuming via environment variables
  
  One mechanism for consuming the downward API is via a container's environment variables.  The
  `EnvVar` type's `valueFrom` field (of type `EnvVarSource`) is used to specify that the variable's
  value should come from a `FieldRef` source instead of the literal value specified by the `value`
  field.  In the future, additional sources may be supported; currently the source's `fieldRef`
  field is used to select a field from the downward API:
  
  Only constant attributes of the pod can be consumed this way, as environment variables cannot be
  updated once a process is started in a way that allows the process to be notified that the value
  of a variable has changed.  The fields supported via environment variables are:
  
  <1>  The pod's name
  <2>  The pod's namespace
  
  As an example:
  
  . Create a `*_pod.json_*` file:
  
  [source,yaml]
  ----
  apiVersion: v1
  
negative.code:             fieldRef:
                fieldPath: metadata.labels <4>
  ----
  <1> The `*metadata*` field of the volume source configures the downward API
  volume.
  <2> The `*items*` field holds a list of fields to project into the volume.
  <3> The name of the file to project the field into.
  <4> The selector of the field to project.
  ====
  
  For example:
  
  . Create a `*_volume-pod.json_*` file:
  +
  ====
  [source,yaml]
  ----
  kind: Pod
  