anchor.diff:  === 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:
  +information about where to send traffic going to the service.
   
   ----
   {
     "kind": "Endpoints",
     "apiVersion": "v1beta3",
     "metadata": {
  -    "name": "external-service" <1>
  +    "name": "example-external-service" <1>
     },
     "endpoints": [ <2>
       "api.mysaas.com:80",
  
positive.code: ----
  
  <1> Other fields on the `DeploymentConfig` are omitted
  
negative.code: === 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:
  
  ----
  {
    "kind": "Service",
    "apiVersion": "v1beta3",
    "metadata": {
      "name": "example-external-service"
    },
    "spec": { <1>
      "port": 1234
  