anchor.diff:  }
   ----
   
  -<1> The service spec must have no `selector` field
  +<1> The `selector` field to leave blank.
  +
  +====
   
   === Setting the endpoints
   
  -The next step is to create endpoints for the service.  This will give the service proxy and router
  -information about where to send traffic going to the service.
  +The next step is to create endpoints for the service. This gives information about where to send traffic going to the
  +service to the service proxy and router.
  +
  +====
   
   ----
   {
  
positive.code: }
  ----
  
  <1> The name must match the name of the `Service` instance
  <2> Traffic to the service will be load-balanced between the supplied `Endpoints`
  
  === 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:
  
  1.  `SAAS_API_KEY`: Holds the API key to use with the service
  2.  `SAAS_USERNAME`: Holds the username to use with the service
  3.  `SAAS_PASSPHRASE`: Holds the passphrase to use with the service
  
  ----
  {
  
negative.code: 
  == Overview
  
  Many OpenShift applications use external resources, such as external databases, or an external
  SaaS endpoint. These external resources can be modeled as native OpenShift services, so that
  applications can work with them as they would any other internal service.
  
  == Example: External SaaS Provider
  
  One of the most common types of external services is an external SaaS endpoint. As an example,
  assume that you want to use a SaaS provider for an application. This requires:
  
  1. An endpoint to communicate with
  2. A set of credentials, such as:
     a.  An API key
     b.  A username
     c.  A passphrase
  
  ////
  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
  ////
  
  The following sections outline a scenario for intergrating with an external SaaS provider:
  
  === Create the service
  
  The first step in integrating with an external service is to create an OpenShift service to represent
  it. This is similar to creating an internal service; however the difference is in the service's `Selector` field.
  
  Internal OpenShift services use the `Selector` field to associate pods with services using 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, leave the `Selector`
  field unset. This makes the `EndpointsController` ignore the service and allows you to specify endpoints manually:
  
  ====
  
  ----
  {
  