anchor.diff:  
   [NOTE]
   ====
  -It is generally preferable to use link:#gfs-supplemental-groups[supplemental
  -group IDs] to gain access to persistent storage versus using user IDs.
  -====
  -
  -In the link:#gfs-mount[example target gluster mount] shown above, the container
  -needs its UID set to 592 (ignoring group IDs for the moment), so the following
  -can be added to the pod definition:
  +Use link:#gfs-supplemental-groups[supplemental group IDs] instead of user IDs to
  +gain access to persistent storage.
  +====
  +
  +In the link:#gfs-mount[target Gluster mount example above], the container needs
  +a UID set to *592*, so the following can be added to the pod definition:
   
   ====
   [source,yaml]
  
positive.code: ----
  ====
  
  Next, define the Gluster endpoints. For example:
  
  .Gluster Endpoints Definition
  ====
  [source,yaml]
  
negative.code:      requests:
         storage: 1Gi <2>
  ----
  <1> `*accessModes*` do not enforce security, but rather act as labels to match a PV to a PVC.
  <2> This claim will look for PVs offering *1Gi* or greater capacity.
  ====
  
  . Save the definition to a file, for example *_gluster-claim.yaml_*, and create
  the PVC:
  +
  ====
  ----
  # oc create -f gluster-claim.yaml
  ----
  ====
  +
  [NOTE]
  ====
  PVs and PVCs make sharing a volume across a project simpler. The
  gluster-specific information contained in the PV definition can also be defined
  directly in a pod specification.
  ====
  
  [[gluster-volume-security]]
  == Volume Security
  
  This section covers Gluster volume security, including matching permissions and
  SELinux considerations. Understanding the basics of POSIX permissions, process
  UIDs, supplemental groups, and SELinux is presumed.
  
  [NOTE]
  ====
  