anchor.diff:      oc scale $dc --replicas=1
     done
   ----
  -endif::openshift-origin[]
  -ifdef::openshift-enterprise[]
  -----
  -$ for dc in $(oc get deploymentconfig --selector logging-infra=elasticsearch -o name); do
  -    oc set volume $dc \
  -          --add --overwrite --name=elasticsearch-storage \
  -          --type=hostPath --path=/usr/local/es-storage
  -    oc scale $dc --replicas=1
  -  done
  -----
  -endif::openshift-enterprise[]
  -
  -If using host mounts is impractical or undesirable, it may be necessary to
  -attach block storage as a
  -xref:../architecture/additional_concepts/storage.adoc#persistent-volume-claims[PersistentVolumeClaim]
  -as in the following example:
  -
  -----
  -$ oc set volume dc/logging-es-<unique> \
  -          --add --overwrite --name=elasticsearch-storage \
  -          --type=persistentVolumeClaim --claim-name=logging-es-1
  -----
  -
  -[WARNING]
  -====
  -Using NFS storage directly or as a PersistentVolume (or via other NAS
  -such as Gluster) is not supported for Elasticsearch storage, as Lucene
  -relies on filesystem behavior that NFS does not supply. Data corruption
  -and other problems can occur. If NFS storage is a requirement, you can
  -allocate a large file on that storage to serve as a storage device and
  -treat it as a host mount on each host. For example:
  -
  -----
  -$ truncate -s 1T /nfs/storage/elasticsearch-1
  -$ mkfs.xfs /nfs/storage/elasticsearch-1
  -$ mount -o loop /nfs/storage/elasticsearch-1 /usr/local/es-storage
  -$ chown 1000:1000 /usr/local/es-storage
  -----
  -
  -Then, use *_/usr/local/es-storage_* as a host-mount as
  -described above. Performance under this solution is significantly
  -worse than using actual local drives.
  -====
  -
  -
  -[[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
  -xref:../admin_guide/managing_projects.adoc#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:
  -
  -====
  -----
  -apiVersion: v1
  -kind: DeploymentConfig
  -spec:
  -  template:
  -    spec:
  -      nodeSelector:
  -        nodelabel: logging-es-node-1
  -----
  -====
  -
  -Alternatively you can use the `oc patch` command:
  -====
  -----
  -$ oc patch dc/logging-es-<unique_name> \
  -   -p '{"spec":{"template":{"spec":{"nodeSelector":{"nodeLabel":"logging-es-node-1"}}}}}'
  -----
  -====
   
   [[scaling-elasticsearch]]
   *Changing the Scale of Elasticsearch*
   
   If you need to scale up the number of Elasticsearch instances your cluster uses,
  -it is not as simple as changing the number of Elasticsearch cluster nodes. This
  +it is not as simple as scaling up an Elasticsearch deployment configuration. This
   is due to the nature of persistent volumes and how Elasticsearch is configured
  -to store its data and recover the cluster. Instead, you must create a deployment
  +to store its data and recover the cluster. Instead, scaling up requires creating a deployment
   configuration for each Elasticsearch cluster node.
   
  +By far the simplest way to change the scale of Elasticsearch is to
  +reinstall the whole deployment. Assuming you have supplied persistent
  +storage for the deployment, this should not be very disruptive. Simply
  +re-run the deployer with the updated `*es-cluster-size*` configuration
  +value and the `*MODE=reinstall*` template parameter. For example:
  +
  +----
  +$ oc edit configmap logging-deployer
  +  [change es-cluster-size value to 5]
  +$ oc new-app logging-deployer-template --param MODE=reinstall
  +----
  +
  +If you previously deployed using template parameters rather than a configmap,
  +this would be a good time to create a configmap instead for future deployer execution.
  +
  +If you do not wish to reinstall, for instance because you have made
  +customizations that you would like to preserve, then it is possible to
  +add new Elasticsearch deployment configurations to the cluster using
  +a template supplied by the deployer. This requires a more complicated
  +procedure however.
  +
   During installation, the deployer
  -xref:../install_config/imagestreams_templates.adoc#install-config-imagestreams-templates[creates templates] with the
  -Elasticsearch configurations provided to it: *logging-es-template* and
  -*logging-es-ops-template* if the deployer was run with
  -`*ENABLE_OPS_CLUSTER=true*`.
  -
  -The node quorum and recovery settings were initially set based on the
  -`*CLUSTER_SIZE*` value provided to the deployer. Since the cluster size is
  -changing, those values need to be updated.
  -
  -. Prior to changing the number of Elasticsearch cluster nodes, the EFK stack
  -should first be scaled down to preserve log data as described in
  -xref:../install_config/upgrading/manual_upgrades.adoc#manual-upgrading-efk-logging-stack[Upgrading
  -the EFK Logging Stack].
  -
  -. Edit the cluster template you are scaling up and change the parameters to the
  -desired value:
  -+
  -- `*NODE_QUORUM*` is the intended cluster size / 2 (rounded down) + 1. For an
  -intended cluster size of 5, the quorum would be 3.
  -+
  -- `*RECOVER_EXPECTED_NODES*` is the same as the intended cluster size.
  -+
  -- `*RECOVER_AFTER_NODES*` is the intended cluster size - 1.
  -+
  -====
  -----
  -$ oc edit template logging-es[-ops]-template
  -----
  -====
  -+
  -. In addition to updating the template, all of the deployment configurations for
  +xref:../install_config/imagestreams_templates.adoc#install-config-imagestreams-templates[creates
  +templates] with the Elasticsearch configurations provided to it:
  +`logging-es-template` (and `logging-es-ops-template` if the deployer was
  +run with `*ENABLE_OPS_CLUSTER=true*`). You can use these for scaling, but
  +you need to adjust the size-related parameters in the templates:
  +
  +[cols="3,7",options="header"]
  +|===
  +|Parameter
  +|Description
  +
  +|`*NODE_QUORUM*`
  +|The quorum required to elect a new master. Should be more than half the intended cluster size.
  +
  +|`*RECOVER_AFTER_NODES*`
  +|When restarting the cluster, require this many nodes to be present before starting recovery.
  +Defaults to one less than the cluster size to allow for one missing node.
  +
  +|`*RECOVER_EXPECTED_NODES*`
  +|When restarting the cluster, wait for this number of nodes to be present before starting recovery.
  +By default, the same as the cluster size.
  +|===
  +
  +The node quorum and recovery settings in the template were set based on the
  +`*es-[ops-]cluster-size*` value initially provided to the deployer. Since the cluster size is
  +changing, those values need to be overridden.
  +
  +. The existing deployment configurations for
   that cluster also need to have the three environment variable values above
  -updated. To edit each of the configurations for the cluster in series, you use
  -the following.
  -+
  -====
  -----
  -$ oc get dc -l component=es[-ops] -o name | xargs -r oc edit
  -----
  -====
  -+
  -. Create an additional deployment configuration, run the following
  +updated. To edit each of the configurations for the cluster in series, you 
  +may use the following command:
  ++
  +====
  +----
  +$ oc edit $(oc get dc -l component=es[-ops] -o name)
  +----
  +====
  ++
  +Edit the environment variables supplied so that the next time they restart,
  +they will begin with the correct values. For example, for a cluster of size
  +5, you would set `*NODE_QUORUM*` to `3`, `*RECOVER_AFTER_NODES*` to `4`, and
  +`*RECOVER_EXPECTED_NODES*` to `5`.
  +
  +. Create additional deployment configuration(s) by running the following
   command against the Elasticsearch cluster you want to to scale up for
  -(*logging-es-template* or *logging-es-ops-template*).
  -+
  -====
  -----
  -$ oc new-app logging-es[-ops]-template
  -----
  -====
  -+
  -These deployments will be named differently, but all will have the *logging-es*
  -prefix. Be aware of the cluster parameters (described in the deployer
  -parameters) based on cluster size that may need corresponding adjustment in the
  -template, as well as existing deployments.
  +(`logging-es-template` or `logging-es-ops-template`), overriding the
  +parameters as above.
  ++
  +====
  +----
  +$ oc new-app logging-es[-ops]-template \
  +     --param NODE_QUORUM=3 \
  +     --param RECOVER_AFTER_NODES=4 \
  +     --param RECOVER_EXPECTED_NODES=5
  +----
  +====
  ++
  +These deployments will be named differently, but all will have the `logging-es`
  +prefix.
  +
  +. Each new deployment configuration is created without a persistent volume. If you want to
  +attach a persistent volume to it, after creation you can
  +use the `oc set volume` command to do so, for example:
  ++
  +----
  +$ oc volume dc/logging-es-<suffix> \
  +          --add --overwrite --name=elasticsearch-storage \
  +          --type=persistentVolumeClaim --claim-name=<your_pvc>`
  +----
   
   . After the intended number of deployment configurations are created, scale up
  -your cluster, starting with Elasticsearch as described in
  -xref:../install_config/upgrading/manual_upgrades.adoc#manual-upgrading-efk-logging-stack[Upgrading
  -the EFK Logging Stack].
  -+
  -[NOTE]
  -====
  -The `oc new-app logging-es[-ops]-template` command creates a deployment
  -configuration with a persistent volume. If you want to create a Elasticsearch
  -cluster node with a persistent volume attached to it, upon creation you can
  -instead run the following command to create your deployment configuration with a
  -persistent volume claim (PVC) attached.
  -
  -----
  -$ oc process logging-es-template | oc volume -f - \
  -          --add --overwrite --name=elasticsearch-storage \
  -          --type=persistentVolumeClaim --claim-name={your_pvc}`
  -----
  -====
  +each new one to deploy it:
  ++
  +----
  +$ oc scale --replicas=1 dc/logging-es-<suffix>
  +----
   
   === Fluentd
   
  -ifdef::openshift-enterprise[]
  -Once Elasticsearch is running, scale Fluentd to every node to feed logs into
  -Elasticsearch. The following example is for an {product-title} instance with
  -three nodes:
  -
  -====
  -----
  -$ oc scale dc/logging-fluentd --replicas=3
  -----
  -====
  -
  -You will need to scale Fluentd if nodes are added or subtracted.
  -endif::openshift-enterprise[]
  -
  -ifdef::openshift-origin[]
   Once Elasticsearch is running, label nodes to enable Fluentd to run on them
  -and feed logs to Elasticsearch. Use the `*FLUENTD_NODESELECTOR*` given to
  +and feed logs to Elasticsearch. Use the `*fluentd-nodeselector*` given to
   the deployer (if different) in the command below:
   
   ====
  
positive.code:   done
  ----
  
  . The Elasticsearch pods must be located on the correct nodes to use
  the local storage, and should not move around even if those nodes are
  taken down for a period of time. This requires giving each Elasticsearch
  replica a node selector that is unique to the node where an administrator
  has allocated storage for it. xref:logging-node-selector[See below
  for directions on setting a node selector].
  
  . Once these steps are taken, a local host mount can be applied to each replica
  as in this example (where we assume storage is mounted at the same path on each node):
  +
  ifdef::openshift-origin[]
  ----
  $ for dc in $(oc get deploymentconfig --selector logging-infra=elasticsearch -o name); do
      oc set volume $dc \
  
negative.code: See the https://www.elastic.co/guide/en/kibana/4.1/discover.html[Kibana
  documentation] for more information on Kibana.
  
  [[configuring-curator]]
  === Curator
  
  Curator allows administrators to configure scheduled Elasticsearch maintenance
  operations to be performed automatically on a per-project basis. It is scheduled
  to perform actions daily based on its configuration. Only one Curator pod is
  recommended per Elasticsearch cluster. Curator is configured via a YAML
  configuration file with the following structure:
  
  ====
  ----
  $PROJECT_NAME:
    $ACTION:
      $UNIT: $VALUE
  
  $PROJECT_NAME:
    $ACTION:
      $UNIT: $VALUE
   ...
  
  ----
  ====
  
  The available parameters are:
  
  [cols="3,7",options="header"]
  |===
  |Variable Name
  |Description
  
  |`*$PROJECT_NAME*`
  |The actual name of a project, such as `myapp-devel`.  For {product-title} `operations`
  logs, use the name `.operations` as the project name.
  
  |`*$ACTION*`
  |The action to take, currently only `delete` is allowed.
  
  |`*$UNIT*`
  |One of `days`, `weeks`, or `months`.
  
  |`*$VALUE*`
  |An integer for the number of units.
  
  |`*.defaults*`
  |Use `.defaults` as the `$PROJECT_NAME` to set the defaults for projects that are
  not specified.
  
  |`*runhour*`
  |(Number) the hour of the day in 24-hour format at which to run the Curator jobs. For
  use with `.defaults`.
  
  |`*runminute*`
  |(Number) the minute of the hour at which to run the Curator jobs. For use with `.defaults`.
  |===
  
  For example, to configure Curator to
  
  - delete indices in the `myapp-dev` project older than `1 day`
  - delete indices in the `myapp-qe` project older than `1 week`
  - delete `operations` logs older than `8 weeks`
  - delete all other projects indices after they are `30 days` old
  - run the Curator jobs at midnight every day
  
  you would use:
  
  ----
  myapp-dev:
   delete:
     days: 1
  
  myapp-qe:
    delete:
      weeks: 1
  
  .operations:
    delete:
      weeks: 8
  
  .defaults:
    delete:
      days: 30
    runhour: 0
    runminute: 0
  ----
  
  
  [IMPORTANT]
  ====
  When you use `month` as the `$UNIT` for an operation, Curator starts counting at
  the first day of the current month, not the current day of the current month.
  For example, if today is April 15, and you want to delete indices that are 2 months
  older than today (delete: months: 2), Curator does not delete indices that are dated
  older than February 15; it deletes indices older than February 1. That is, it
  goes back to the first day of the current month, then goes back two whole months
  from that date. If you want to be exact with Curator, it is best to use days
  (for example, `delete: days: 30`).
  ====
  
  [[aggregate-logging-creating-the-curator-configuration]]
  ==== Creating the Curator Configuration
  
  The deployer provides a configmap from which Curator reads its
  configuration.  You may edit or replace this configmap to reconfigure
  Curator. Currently the `logging-curator` configmap is used to
  configure both your ops and non-ops Curator instances. Any `.operations`
  configurations will be in the same location as your application logs
  configurations.
  
  . To edit the provided configmap to configure your Curator instances:
  +
  ----
  $ oc edit configmap/logging-curator
  ----
  
  . To replace the provided configmap instead:
  +
  ----
  $ create /path/to/mycuratorconfig.yaml
  $ oc create configmap logging-curator -o yaml \
    --from-file=config.yaml=/path/to/mycuratorconfig.yaml | \
    oc replace -f -
  ----
  
  . After you make your changes, redeploy Curator:
  +
  ----
  $ oc deploy --latest dc/logging-curator
  $ oc deploy --latest dc/logging-curator-ops
  ----
  
  == Cleanup
  
  You can remove everything generated during the deployment while
  leaving other project contents intact:
  
  ----
  $ oc new-app logging-deployer-template --param MODE=uninstall
  ----
  
  [[aggregate-logging-upgrading]]
  