anchor.diff:  = Cluster Controller
   
   The cluster controller is in charge of deploying a Kafka cluster alongside a Zookeeper ensemble. It's also able to deploy a
  -Kafka Connect cluster which connects to an existing Kafka cluster.
  +Kafka Connect cluster which connects to an existing Kafka cluster. Such a cluster can be deployed using the Source2Image OpenShift
  +feature as well in order to include more connectors plugins.
   
   When the cluster controller is up and running, it starts to "watch" for ConfigMaps containing the Kafka or Kafka Connect
  -cluster configuration. Such ConfigMaps need to have a specific label which by default is `strimzi.io/kind=cluster` (as described later)
  +cluster configuration. Such ConfigMaps need to have a specific label which is, by default, `strimzi.io/kind=cluster` (as described later)
   that can be changed through a corresponding environment variable.
   
  -When a new ConfigMap is created on the Kubernetes/OpenShift cluster, the controller gets the cluster configuration from
  -its `data` section and starts the creation process of a new cluster (Kafka or Kafka Connect). It's done creating a set
  -of Kubernetes/OpenShift resources needed for such a cluster, like StatefulSets, ConfigMaps, Services and so on.
  -
  -Every time the ConfigMap is updated by the user with some changes in the `data` section, the controller executes a related updating
  -operation on the cluster (i.e. scale up/down, changing metrics configuration and so on). It means that some resources are 
  -patched or deleted and then re-created for reflecting the changes in the cluster configuration.
  -This might cause rolling update which might lead to service disruption.
  +When a new ConfigMap is created in the Kubernetes/OpenShift cluster, the controller gets the cluster configuration from
  +its `data` section and starts creating a new Kafka or Kafka Connect cluster by creating the necessary Kubernetes/OpenShift
  +resources, such as StatefulSets, ConfigMaps, Services etc.
  +
  +Every time the ConfigMap is updated by the user with some changes in the `data` section, the controller performs corresponding
  +updates on the Kubernetes/OpenShift resources which make up the Kafka or Kafka Connect cluster. Resources are either patched
  +or deleted and then re-created in order to make the Kafka or Kafka Connect cluster reflect the state of the cluster ConfigMap.
  +This might cause a rolling update which might lead to service disruption.
   
   Finally, if the ConfigMap is deleted, the controller starts to un-deploy the cluster deleting all the related Kubernets/OpenShift
   resources.
   
   == Reconciliation
   
  -When the controller is up and running, it reacts at all notifications received from the Kubernetes/OpenShift cluster related 
  -to the watched ConfigMaps when they are created, updated or deleted.
  +When the controller is running it reacts to all notifications about the cluster ConfigMaps received from the Kubernetes/OpenShift cluster.
  +However if the controller is not running, or if a notification is not received for any reason it could lose notifications
  +about the cluster ConfigMaps.
   
   For different reasons, it could lose notifications about the cluster ConfigMaps; without any action there will be an
  -inconsistent state comparing to the ConfigMaps and what is actually deployed in the Kubernetes/OpenShift cluster.
  -
  -In order to handle failovers in a proper way, a periodic reconciliation process is executed by the cluster controller so
  -that it can compare how the ConfigMaps look like (and if they exist) with the current cluster deployment in order to have
  +inconsistency between the cluster ConfigMaps and the state of the running Kubernetes/OpenShift cluster.
  +
  +In order to handle failovers properly, a periodic reconciliation process is executed by the cluster controller so
  +that it can compare the state of the ConfigMaps with the current cluster deployment in order to have
   a consistent state across all of them.
   
   == Format of the cluster ConfigMap
  
positive.code: features (works only with OpenShift)
  
  The `data` section of such ConfigMaps contains different keys depending on the "type" of deployment as described in the 
  following paragraphs.
  
  === Kafka
  
  
negative.code: * `zookeeper-metrics-config`: a JSON string representing the JMX exporter configuration for exposing metrics from Zookeeper nodes.
   Removing this field means having no metrics exposed.
   
  The following is an example of a ConfigMap for a Kakfa cluster.
  
  .Example Kafka cluster ConfigMap
  [source,yaml,options="nowrap"]
  ----
  apiVersion: v1
  