anchor.diff:  }
   ----
   
  -<1> The name must match the name of the `Service` instance
  +<1> The name of the `Service` instance.
   <2> Traffic to the service will be load-balanced between the supplied `Endpoints` if more than one
  -    is supplied
  -
  -=== Consuming credentials in pods
  +    is supplied.
  +
  +====
  +
  +=== Consuming Credentials in Pods
   
   Now that the service and endpoints are defined, we need to give pods the credentials to use the
  -service.  This is done by setting environment variables in the appropriate containers.  In this
  -example, the container will receive the following environment variables with credentials for the
  +service by setting environment variables in the appropriate containers. In the following
  +example, the container receives the following environment variables with credentials for the
   service:
   
  -1.  `MYSQL_USERNAME`: Holds the username to use with the service
  -2.  `MYSQL_PASSPHRASE`: Holds the passphrase to use with the service
  -3.  `MYSQL_DATABASE_NAME`: Holds the database name to use
  +*  `MYSQL_USERNAME`: The username to use with the service.
  +*  `MYSQL_PASSPHRASE`: The passphrase to use with the service.
  +*  `MYSQL_DATABASE_NAME`: The database name.
  +
  +====
   
   ----
   {
  
positive.code: applications can work with them as they would any other internal service.
  
  
  == Example: External MySQL Database
  
  One of the most common types of external services is an external database.  As an example,
  assume that you want to use an external mysql database.  Your application needs:
  
  1. An endpoint to communicate with
  2. A set of credentials and coordinates:
     a.  A username
     b.  A passphrase
     c.  A database name
  
  The formula for integrating with this type of external resource is fairly simple.  The pieces of
  the solution are:
  
  1.  A `Service` object to represent the SaaS provider as an OpenShift service
  2.  One or more `Endpoints` for the service
  3.  Environment variables in the appropriate pods that contain the credentials
  
  === Creating the service
  
  The first step in integrating with an external service is to create an OpenShift service to
  represent it.  This is very similar to creating an internal service; the difference is in the
  service's `Selector` field.
  
  Internal OpenShift services use the `Selector` field to associate pods with services
  via labels.  A system component called `EndpointsController` synchronizes the endpoints for
  services that specify selectors with the pods that match the selector.  The service proxy and
  OpenShift router load-balance requests to the service amongst the service's endpoints.
  
  The only difference between an internal OpenShift service and a service that represents an external
  resource is that there are no pods to associate an external service with.  To represent external
  services, we just need to leave the `Selector` field unset.  This will make the `EndpointsController`
  ignore the service and allow you to specify endpoints manually:
  
  ----
  {
  
negative.code: }
  ----
  
  <1> The `selector` field to leave blank.
  
  ====
  
  === Setting the Endpoints
  
  The next step is to create endpoints for the service. This gives the service proxy and router
  the location to send traffic going to the service.
  
  ====
  
  ----
  {
  