anchor.diff:  ----
   $ oc volume dc/logging-es-<suffix> \
             --add --overwrite --name=elasticsearch-storage \
  -          --type=persistentVolumeClaim --claim-name=<your_pvc>`
  +          --type=persistentVolumeClaim --claim-name=<your_pvc>
   ----
   
   . After the intended number of deployment configurations are created, scale up
  
positive.code: create a deployer pod that reads the deployment parameters and manages
  the deployment.
  
  . Run the deployer, optionally specifying parameters (described in the table below), for example:
  +
  ====
  Without template parameters:
  
  
negative.code: |*_MODE_* (default: *install*)
  | Mode to run the deployer in; one of `*install, uninstall, reinstall, upgrade, migrate, start, stop*`.
  |===
  
  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 for {product-title} to retrieve the deployer image
  from the registry. You can watch its process with:
  
  ----
  $ oc get pod/<pod_name> -w
  ----
  
  It should eventually enter Running status and end in Complete status.
  If it seems to be taking too long to start, you can retrieve more details about
  the pod and any associated events with:
  
  ----
  $ oc describe pod/<pod_name>
  ----
  
  You can also check the logs if the deployment does not complete successfully:
  
  ----
  $ oc logs -f <pod_name>
  ----
  
  Once deployment completes successfully, you will probably need to
  xref:aggregate_logging.adoc#aggregated-fluentd[label the nodes for
  Fluentd to deploy on], and may have other adjustments to make to the
  deployed components. These are described in the next section.
  
  == Understanding and Adjusting the Deployment
  
  [[aggregated-ops]]
  === Ops Cluster
  
  [NOTE]
  ====
  The logs for the *default*, *openshift*, and *openshift-infra* projects are automatically aggregated and grouped into the *.operations* item in the Kibana interface.
  
  The project where you have deployed the EFK stack (*logging*, as documented here) is _not_ aggregated into *.operations* and is found under its ID.
  ====
  
  If you set `*enable-ops-cluster*` to `true` for the deployer, Fluentd
  is configured to split logs between the main ElasticSearch cluster
  