anchor.diff:  [[logging-node-selector]]
   *Node Selector*
   
  -Because Elasticsearch can use a lot of resources, all members of a cluster should
  -have low latency network connections to each other. Ensure this by directing the
  -instances to dedicated nodes, or a dedicated region within your cluster, using a
  -node selector.
  +Because Elasticsearch can use a lot of resources, all members of a cluster
  +should have low latency network connections to each other. Ensure this by
  +directing the instances to dedicated nodes, or a dedicated region within your
  +cluster, using a
  +link:../admin_guide/managing_projects.html#using-node-selectors[node selector].
   
   To configure a node selector, edit each deployment configuration and add the
   `*nodeSelector*` parameter to specify the label of the desired nodes:
  
positive.code: ====
  +
  Then, enable the *logging-deployer* service account to edit the project
  contents. By default service accounts are not allowed to do this.
  The following example uses the `logging` project. Be sure to use the
  project created above in the following example:
  +
  ====
  ----
  
negative.code: |Variables for the operations log cluster.
  |===
  +
  [NOTE]
  ====
  When setting the `*ENABLE_OPS_CLUSTER*` parameter to `*true*`, Fluentd splits
  logs between the Elasticsearch cluster and a cluster reserved for operations
  logs. This means a second Elasticsearch and Kibana are deployed. The deployments
  are distinguishable by the *-ops* included in their names.
  ====
  +
  Running the deployer creates a deployer pod and prints its name. Wait until the
  pod is running. This can take up to a few minutes to retrieve the deployer image
  from the registry. You can watch its process with:
  +
  ----
  $ oc get pod/<pod_name> -w
  ----
  +
  If it seems to be taking too long, you can retrieve more details about the pod
  and any associated events with:
  +
  ----
  $ oc describe pod/<pod_name>
  ----
  +
  When it runs, you can check the logs of the resulting pod to see if the
  deployment was successful:
  +
  ----
  $ oc logs -f <pod_name>
  ----
  
  . As a cluster administrator, deploy a template that is created by the deployer:
  +
  ====
  ----
  