anchor.diff:  ----
   ====
   
  -Next, define the Gluster endpoints. For example:
  -
  +. Define the Gluster endpoints:
  ++
   .Gluster Endpoints Definition
   ====
   [source,yaml]
  
positive.code:   ports:
    - port: 1
  ----
  <1> this name must be defined in the endpoints definition to match the endpoints to this service
  ====
  
  Save the service definition to a file, for example *_gluster-service.yaml_*,
  then create the service:
  
  ====
  ----
  $ oc create -f gluster-service.yaml
  service "glusterfs-cluster" created
  ----
  ====
  
  Verify that the service was created:
  
  ====
  ----
  # oc get services
  
negative.code:     supplementalGroups: [590] <2>
  ----
  <1> `*securityContext*` must be defined at the pod level, not under a specific container.
  <2> An array of GIDs defined at the pod level.
  ====
  
  Assuming there are no custom SCCs that satisfy the pod's requirements, the pod
  matches the *restricted* SCC. This SCC has the `*supplementalGroups*` strategy
  set to *RunAsAny*, meaning that any supplied group IDs are accepted without
  range checking.
  
  As a result, the above pod will pass admissions and can be launched. However, if
  group ID range checking is desired, use a custom SCC, as described in
  link:pod_security_context#scc-supplemental-groups[pod security and custom SCCs].
  A custom SCC can be created to define minimum and maximum group IDs, enforce
  group ID range checking, and allow a group ID of *590*.
  
  [[gfs-user-ids]]
  === User IDs
  