RHDEVDOCS-3018 Document: [Logging 5.1]EO shouldn't try to upgrade ES cluster after adding/removing storage.

// Module included in the following assemblies:
//
// * logging/cluster-logging-log-store.adoc

[id="cluster-logging-log-store-comp-viewing_{context}"]
= Viewing the status of the log store

You can view the status of your log store.

.Prerequisites

* OpenShift Logging and Elasticsearch must be installed.

.Procedure

. Change to the `openshift-logging` project.
+
[source,terminal]
----
$ oc project openshift-logging
----

. To view the status:

.. Get the name of the log store instance:
+
[source,terminal]
----
$ oc get Elasticsearch
----
+
.Example output
[source,terminal]
----
NAME            AGE
elasticsearch   5h9m
----

.. Get the log store status:
+
[source,terminal]
----
$ oc get Elasticsearch <Elasticsearch-instance> -o yaml
----
+
For example:
+
[source,terminal]
----
$ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml
----
+
The output includes information similar to the following:
+
.Example output
[source,terminal]
----
status: <1>
  cluster: <2>
    activePrimaryShards: 30
    activeShards: 60
    initializingShards: 0
    numDataNodes: 3
    numNodes: 3
    pendingTasks: 0
    relocatingShards: 0
    status: green
    unassignedShards: 0
  clusterHealth: ""
  conditions: [] <3>
  nodes: <4>
  - deploymentName: elasticsearch-cdm-zjf34ved-1
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-2
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-3
    upgradeStatus: {}
  pods: <5>
    client:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    data:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    master:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
  shardAllocationEnabled: all
----
<1> In the output, the cluster status fields appear in the `status` stanza.
<2> The status of the log store:
+
* The number of active primary shards.
* The number of active shards.
* The number of shards that are initializing.
* The number of log store data nodes.
* The total number of log store nodes.
* The number of pending tasks.
* The log store status: `green`, `red`, `yellow`.
* The number of unassigned shards.
<3> Any status conditions, if present. The log store status indicates the reasons from the scheduler if a pod could not be placed. Any events related to the following conditions are shown:
* Container Waiting for both the log store and proxy containers.
* Container Terminated for both the log store and proxy containers.
* Pod unschedulable.
Also, a condition is shown for a number of issues; see *Example condition messages*.
<4> The log store nodes in the cluster, with `upgradeStatus`.
<5> The log store client, data, and master pods in the cluster, listed under 'failed`, `notReady`, or `ready` state.

[id="cluster-logging-elasticsearch-status-message_{context}"]
== Example condition messages

The following are examples of some condition messages from the `Status` section of the Elasticsearch instance.

// https://github.com/openshift/elasticsearch-operator/pull/92

The following status message indicates that a node has exceeded the configured low watermark, and no shard will be allocated to this node.

[source,yaml]
----
status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
----

The following status message indicates that a node has exceeded the configured high watermark, and shards will be relocated to other nodes.

[source,yaml]
----
status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
----

The following status message indicates that the log store node selector in the CR does not match any nodes in the cluster:

[source,yaml]
----
status:
    nodes:
    - conditions:
      - lastTransitionTime: 2019-04-10T02:26:24Z
        message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
        reason: Unschedulable
        status: "True"
        type: Unschedulable
----

The following status message indicates that the log store CR uses a non-existent persistent volume claim (PVC).

[source,yaml]
----
status:
   nodes:
   - conditions:
     - last Transition Time:  2019-04-10T05:55:51Z
       message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
       reason:                Unschedulable
       status:                True
       type:                  Unschedulable
----

The following status message indicates that your log store cluster does not have enough nodes to support the redundancy policy.

[source,yaml]
----
status:
  clusterHealth: ""
  conditions:
  - lastTransitionTime: 2019-04-17T20:01:31Z
    message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
      add more nodes with data roles
    reason: Invalid Settings
    status: "True"
    type: InvalidRedundancy
----

This status message indicates your cluster has too many control plane nodes (also known as the master nodes):

[source,yaml]
----
status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: '2019-04-17T20:12:34Z'
      message: >-
        Invalid master nodes count. Please ensure there are no more than 3 total
        nodes with master roles
      reason: Invalid Settings
      status: 'True'
      type: InvalidMasters
----

The following status message indicates that Elasticsearch storage does not support the change you tried to make.

For example:
[source,yaml]
----
status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: "2021-05-07T01:05:13Z"
      message: Changing the storage structure for a custom resource is not supported
      reason: StorageStructureChangeIgnored
      status: 'True'
      type: StorageStructureChangeIgnored
----

The `reason` and `type` fields specify the type of unsupported change:

`StorageClassNameChangeIgnored`:: Unsupported change to the storage class name.
`StorageSizeChangeIgnored`:: Unsupported change the storage size.
`StorageStructureChangeIgnored`:: Unsupported change between ephemeral and persistent storage structures.
+
[IMPORTANT]
====
If you try to configure the `ClusterLogging` custom resource (CR) to switch from ephemeral to persistent storage, the OpenShift Elasticsearch Operator creates a persistent volume claim (PVC) but does not create a persistent volume (PV). To clear the `StorageStructureChangeIgnored` status, you must revert the change to the `ClusterLogging` CR and delete the PVC.
====

// Module included in the following assemblies:
//
// * logging/cluster-logging-log-store.adoc

[id="cluster-logging-log-store-comp-viewing_{context}"]
= Viewing the status of the log store

You can view the status of your log store.

.Prerequisites

* OpenShift Logging and Elasticsearch must be installed.

.Procedure

. Change to the `openshift-logging` project.
+
[source,terminal]
----
$ oc project openshift-logging
----

. To view the status:

.. Get the name of the log store instance:
+
[source,terminal]
----
$ oc get Elasticsearch
----
+
.Example output
[source,terminal]
----
NAME            AGE
elasticsearch   5h9m
----

.. Get the log store status:
+
[source,terminal]
----
$ oc get Elasticsearch <Elasticsearch-instance> -o yaml
----
+
For example:
+
[source,terminal]
----
$ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml
----
+
The output includes information similar to the following:
+
.Example output
[source,terminal]
----
status: <1>
  cluster: <2>
    activePrimaryShards: 30
    activeShards: 60
    initializingShards: 0
    numDataNodes: 3
    numNodes: 3
    pendingTasks: 0
    relocatingShards: 0
    status: green
    unassignedShards: 0
  clusterHealth: ""
  conditions: [] <3>
  nodes: <4>
  - deploymentName: elasticsearch-cdm-zjf34ved-1
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-2
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-3
    upgradeStatus: {}
  pods: <5>
    client:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    data:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    master:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
  shardAllocationEnabled: all
----
<1> In the output, the cluster status fields appear in the `status` stanza.
<2> The status of the log store:
+
* The number of active primary shards.
* The number of active shards.
* The number of shards that are initializing.
* The number of log store data nodes.
* The total number of log store nodes.
* The number of pending tasks.
* The log store status: `green`, `red`, `yellow`.
* The number of unassigned shards.
<3> Any status conditions, if present. The log store status indicates the reasons from the scheduler if a pod could not be placed. Any events related to the following conditions are shown:
* Container Waiting for both the log store and proxy containers.
* Container Terminated for both the log store and proxy containers.
* Pod unschedulable.
Also, a condition is shown for a number of issues, see *Example condition messages*.
<4> The log store nodes in the cluster, with `upgradeStatus`.
<5> The log store client, data, and master pods in the cluster, listed under 'failed`, `notReady` or `ready` state.

[id="cluster-logging-elasticsearch-status-message_{context}"]
== Example condition messages

The following are examples of some condition messages from the `Status` section of the Elasticsearch instance.

// https://github.com/openshift/elasticsearch-operator/pull/92

This status message indicates a node has exceeded the configured low watermark and no shard will be allocated to this node.

[source,yaml]
----
status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
----

This status message indicates a node has exceeded the configured high watermark and shards will be relocated to other nodes.

[source,yaml]
----
status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
----

This status message indicates the log store node selector in the CR does not match any nodes in the cluster:

[source,yaml]
----
status:
    nodes:
    - conditions:
      - lastTransitionTime: 2019-04-10T02:26:24Z
        message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
        reason: Unschedulable
        status: "True"
        type: Unschedulable
----

This status message indicates that the log store CR uses a non-existent PVC.

[source,yaml]
----
status:
   nodes:
   - conditions:
     - last Transition Time:  2019-04-10T05:55:51Z
       message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
       reason:                Unschedulable
       status:                True
       type:                  Unschedulable
----

This status message indicates that your log store cluster does not have enough nodes to support your log store redundancy policy.

[source,yaml]
----
status:
  clusterHealth: ""
  conditions:
  - lastTransitionTime: 2019-04-17T20:01:31Z
    message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
      add more nodes with data roles
    reason: Invalid Settings
    status: "True"
    type: InvalidRedundancy
----

This status message indicates your cluster has too many control plane nodes (also known as the master nodes):

[source,yaml]
----
status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: '2019-04-17T20:12:34Z'
      message: >-
        Invalid master nodes count. Please ensure there are no more than 3 total
        nodes with master roles
      reason: Invalid Settings
      status: 'True'
      type: InvalidMasters
----


Related image block is defined to use image as the key

The value as the yaml key for the image pull spec in related images
is not correct it should be image`.

// Module included in the following assemblies:
//
// * operators/operator_sdk/osdk-generating-csvs.adoc

[id="olm-enabling-operator-for-restricted-network_{context}"]
= Enabling your Operator for restricted network environments

As an Operator author, your CSV must meet the following additional requirements
for your Operator to run properly in a restricted network environment:

* List any _related images_, or other container images that your Operator might
require to perform their functions.
* Reference all specified images by a digest (SHA) and not by a tag.

You must use SHA references to related images in two places in the Operator's
CSV:

* in `spec.relatedImages`:
+
[source,yaml]
----
...
spec:
  relatedImages: <1>
    - name: etcd-operator <2>
      image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 <3>
    - name: etcd-image
      image: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68
...
----
<1> Create a `relatedImages` section and set the list of related images.
<2> Specify a unique identifier for the image.
<3> Specify each image by a digest (SHA), not by an image tag.

* in the `env` section of the Operators Deployments when declaring environment
variables that inject the image that the Operator should use:
+
[source,yaml]
----
spec:
  install:
    spec:
      deployments:
      - name: etcd-operator-v3.1.1
        spec:
          replicas: 1
          selector:
            matchLabels:
              name: etcd-operator
          strategy:
            type: Recreate
          template:
            metadata:
              labels:
                name: etcd-operator
            spec:
              containers:
              - args:
                - /opt/etcd/bin/etcd_operator_run.sh
                env:
                - name: WATCH_NAMESPACE
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.annotations['olm.targetNamespaces']
                - name: ETCD_OPERATOR_DEFAULT_ETCD_IMAGE <1>
                  value: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68 <2>
                - name: ETCD_LOG_LEVEL
                  value: INFO
                image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 <3>
                imagePullPolicy: IfNotPresent
                livenessProbe:
                  httpGet:
                    path: /healthy
                    port: 8080
                  initialDelaySeconds: 10
                  periodSeconds: 30
                name: etcd-operator
                readinessProbe:
                  httpGet:
                    path: /ready
                    port: 8080
                  initialDelaySeconds: 10
                  periodSeconds: 30
                resources: {}
              serviceAccountName: etcd-operator
    strategy: deployment
----
<1> Inject the images referenced by the Operator via environment variables.
<2> Specify each image by a digest (SHA), not by an image tag.
<3> Also reference the Operator container image by a digest (SHA), not by an image tag.

* Look for the `Disconnected` annotation, which indicates that the Operator works
in a disconnected environment:
+
[source,yaml]
----
metadata:
  annotations:
    operators.openshift.io/infrastructure-features: '["Disconnected"]'
----
+
Operators can be filtered in OperatorHub by this infrastructure feature.

// Module included in the following assemblies:
//
// * operators/operator_sdk/osdk-generating-csvs.adoc

[id="olm-enabling-operator-for-restricted-network_{context}"]
= Enabling your Operator for restricted network environments

As an Operator author, your CSV must meet the following additional requirements
for your Operator to run properly in a restricted network environment:

* List any _related images_, or other container images that your Operator might
require to perform their functions.
* Reference all specified images by a digest (SHA) and not by a tag.

You must use SHA references to related images in two places in the Operator's
CSV:

* in `spec.relatedImages`:
+
[source,yaml]
----
...
spec:
  relatedImages: <1>
    - name: etcd-operator <2>
      value: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 <3>
    - name: etcd-image
      value: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68
...
----
<1> Create a `relatedImages` section and set the list of related images.
<2> Specify a unique identifier for the image.
<3> Specify each image by a digest (SHA), not by an image tag.

* in the `env` section of the Operators Deployments when declaring environment
variables that inject the image that the Operator should use:
+
[source,yaml]
----
spec:
  install:
    spec:
      deployments:
      - name: etcd-operator-v3.1.1
        spec:
          replicas: 1
          selector:
            matchLabels:
              name: etcd-operator
          strategy:
            type: Recreate
          template:
            metadata:
              labels:
                name: etcd-operator
            spec:
              containers:
              - args:
                - /opt/etcd/bin/etcd_operator_run.sh
                env:
                - name: WATCH_NAMESPACE
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.annotations['olm.targetNamespaces']
                - name: ETCD_OPERATOR_DEFAULT_ETCD_IMAGE <1>
                  value: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68 <2>
                - name: ETCD_LOG_LEVEL
                  value: INFO
                image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 <3>
                imagePullPolicy: IfNotPresent
                livenessProbe:
                  httpGet:
                    path: /healthy
                    port: 8080
                  initialDelaySeconds: 10
                  periodSeconds: 30
                name: etcd-operator
                readinessProbe:
                  httpGet:
                    path: /ready
                    port: 8080
                  initialDelaySeconds: 10
                  periodSeconds: 30
                resources: {}
              serviceAccountName: etcd-operator
    strategy: deployment
----
<1> Inject the images referenced by the Operator via environment variables.
<2> Specify each image by a digest (SHA), not by an image tag.
<3> Also reference the Operator container image by a digest (SHA), not by an image tag.

* Look for the `Disconnected` annotation, which indicates that the Operator works
in a disconnected environment:
+
[source,yaml]
----
metadata:
  annotations:
    operators.openshift.io/infrastructure-features: '["Disconnected"]'
----
+
Operators can be filtered in OperatorHub by this infrastructure feature.


[release] Changelog for 1.1.0.Beta1

[release] Changelog for 1.1.0.Beta1

= Release Notes for Debezium 1.1
:awestruct-layout: doc
:awestruct-documentation_version: "1.1"
:toc:
:toc-placement: macro
:toclevels: 1
:sectanchors:
:linkattrs:
:icons: font

All notable changes for Debezium releases are documented in this file.
Release numbers follow http://semver.org[Semantic Versioning].

toc::[]

[[release-1.1.0-beta1]]
== *Release 1.1.0.Beta1* _(February 5th, 2020)_

See the https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317320&version=12344479[complete list of issues].

=== Kafka compatibility

This release has been built against Kafka Connect 2.4.0 and has been tested with version 2.4.0 of the Kafka brokers.
See the https://kafka.apache.org/documentation/#upgrade[Kafka documentation] for compatibility with other versions of Kafka brokers.

=== Upgrading

Before upgrading the MySQL, MongoDB, PostgreSQL or SQL Server connectors, be sure to check the backward-incompatible changes that have been made since the release you were using.

When you decide to upgrade one of these connectors to 1.1.0.Beta1 from any of the earlier 1.1.x, 1.0.x, 0.10.x, 0.9.x, 0.8.x, 0.7.x, 0.6.x, 0.5.x, 0.4.x, 0.3.x, 0.2.x, or 0.1.x versions,
first check the upgrading notes for the version you're using.
Gracefully stop the running connector, remove the old plugin files, install the 1.1.0.Beta1 plugin files, and restart the connector using the same configuration.
Upon restart, the 1.1.0.Beta1 connectors will continue where the previous connector left off.
As one might expect, all change events previously written to Kafka by the old connector will not be modified.

If you are using our docker images then do not forget to pull them fresh from Docker registry.

=== Breaking changes

Before updating the DecoderBufs logical decoding plug-in in your Postgres database to this new version (or when pulling the debezium/postgres container image for that new version), it is neccessary to upgrade the Debezium Postgres connector to 1.0.1.Final or 1.1.0.Alpha2 or later (https://issues.jboss.org/browse/DBZ-1052[DBZ-1052]).

The `ExtractNewDocumentState` SMT to be used with the Debezium MongoDB connector will convert `Date` and `Timestamp` fields now into the `org.apache.kafka.connect.data.Timestam`p logical type, clarifying its semantics.
The schema type itself remains unchanged as `int64`.
Please note that the resolution of `Timestamp` is seconds as per the semantics of that type in MongoDB. (https://issues.jboss.org/browse/DBZ-1717[DBZ-1717]).

=== New Features

* Create a plug-in for DB2 streaming https://issues.jboss.org/browse/DBZ-695[DBZ-695]
* Add topic routing by field option for New Record State Extraction https://issues.jboss.org/browse/DBZ-1715[DBZ-1715]
* Generate date(time) field types in the Kafka Connect data structure https://issues.jboss.org/browse/DBZ-1717[DBZ-1717]
* Publish TX boundary markers on a TX metadata topic https://issues.jboss.org/browse/DBZ-1052[DBZ-1052]
* Replace connectorName with kafkaTopicPrefix in kafka key/value schema https://issues.jboss.org/browse/DBZ-1763[DBZ-1763]

=== Fixes

This release includes the following fixes:

* Connector error after adding a new not null column to table in Postgres https://issues.jboss.org/browse/DBZ-1698[DBZ-1698]
* MySQL connector doesn't use default value of connector.port https://issues.jboss.org/browse/DBZ-1712[DBZ-1712]
* Fix broken images in Antora and brush up AsciiDoc  https://issues.jboss.org/browse/DBZ-1725[DBZ-1725]
* ANTLR parser cannot parse MariaDB Table DDL with TRANSACTIONAL attribute https://issues.jboss.org/browse/DBZ-1733[DBZ-1733]
* Postgres connector does not support proxied connections https://issues.jboss.org/browse/DBZ-1738[DBZ-1738]
* GET DIAGNOSTICS statement not parseable https://issues.jboss.org/browse/DBZ-1740[DBZ-1740]
* Examples use http access to Maven repos which is no longer available https://issues.jboss.org/browse/DBZ-1741[DBZ-1741]
* MySql password logged out in debug log level https://issues.jboss.org/browse/DBZ-1748[DBZ-1748]
* Cannot shutdown PostgreSQL if there is an active Debezium connector https://issues.jboss.org/browse/DBZ-1727[DBZ-1727]

=== Other changes

This release includes also other changes:

* Add tests for using fallback values with default REPLICA IDENTITY https://issues.jboss.org/browse/DBZ-1158[DBZ-1158]
* Migrate all attribute name/value pairs to Antora component descriptors https://issues.jboss.org/browse/DBZ-1687[DBZ-1687]
* Upgrade to Awestruct 0.6.0 https://issues.jboss.org/browse/DBZ-1719[DBZ-1719]
* Run CI tests for delivered non-connector modules (like Quarkus) https://issues.jboss.org/browse/DBZ-1724[DBZ-1724]
* Remove overlap of different documentation config files https://issues.jboss.org/browse/DBZ-1729[DBZ-1729]
* Don't fail upon receiving unkown operation events https://issues.jboss.org/browse/DBZ-1747[DBZ-1747]
* Provide a method to identify an envelope schema https://issues.jboss.org/browse/DBZ-1751[DBZ-1751]
* Upgrade to Mongo Java Driver version 3.12.1 https://issues.jboss.org/browse/DBZ-1761[DBZ-1761]
* Create initial Proposal for DB2 Source Connector https://issues.jboss.org/browse/DBZ-1509[DBZ-1509]
* Review Pull Request for DB2 Connector https://issues.jboss.org/browse/DBZ-1527[DBZ-1527]
* Test Set up of the DB2 Test Instance https://issues.jboss.org/browse/DBZ-1556[DBZ-1556]
* Create Documentation for the DB2 Connector https://issues.jboss.org/browse/DBZ-1557[DBZ-1557]
* Verify support of all DB2 types https://issues.jboss.org/browse/DBZ-1708[DBZ-1708]

[[release-1.1.0-alpha1]]
== *Release 1.1.0.Alpha1* _(January 16th, 2020)_

See the https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317320&version=12344080[complete list of issues].

=== Kafka compatibility

This release has been built against Kafka Connect 2.4.0 and has been tested with version 2.4.0 of the Kafka brokers.
See the https://kafka.apache.org/documentation/#upgrade[Kafka documentation] for compatibility with other versions of Kafka brokers.

=== Upgrading

Before upgrading the MySQL, MongoDB, PostgreSQL or SQL Server connectors, be sure to check the backward-incompatible changes that have been made since the release you were using.

When you decide to upgrade one of these connectors to 1.1.0.Alpha1 from any of the earlier 1.1.x, 1.0.x, 0.10.x, 0.9.x, 0.8.x, 0.7.x, 0.6.x, 0.5.x, 0.4.x, 0.3.x, 0.2.x, or 0.1.x versions,
first check the upgrading notes for the version you're using.
Gracefully stop the running connector, remove the old plugin files, install the 1.1.0.Alpha1 plugin files, and restart the connector using the same configuration.
Upon restart, the 1.1.0.Alpha1 connectors will continue where the previous connector left off.
As one might expect, all change events previously written to Kafka by the old connector will not be modified.

If you are using our docker images then do not forget to pull them fresh from Docker registry.

=== Breaking changes

When using the outbox event routing SMT and configuring a column from which to obtain the Kafka record timestamp from (table.field.event.timestamp option), then that value could have been exported as milliseconds, microseconds or nanoseconds, based on the source column's definition.
As of this release, the timestamp always be exported as milliseconds (https://issues.jboss.org/browse/DBZ-1707[DBZ-1707]).

The deprecated Postgres connector option `slot.drop_on_stop` has been removed; use `slot.drop.on.stop` instead (https://issues.jboss.org/browse/DBZ-1600[DBZ-1600]).

=== New Features

* MongoDB authentication against non-admin authsource https://issues.jboss.org/browse/DBZ-1168[DBZ-1168]
* Oracle: Add support for different representations of "NUMBER" Data Type https://issues.jboss.org/browse/DBZ-1552[DBZ-1552]
* Update Mongo Java driver to version 3.12.0 https://issues.jboss.org/browse/DBZ-1690[DBZ-1690]
* Support exporting change events in "CloudEvents" format https://issues.jboss.org/browse/DBZ-1292[DBZ-1292]
* Build Quarkus extension facilitating implementations of the outbox pattern https://issues.jboss.org/browse/DBZ-1478[DBZ-1478]
* Support column masking option for Postgres https://issues.jboss.org/browse/DBZ-1685[DBZ-1685]

=== Fixes

This release includes the following fixes:

* Make slot creation in PostgreSQL more resilient https://issues.jboss.org/browse/DBZ-1684[DBZ-1684]
* SQLserver type time(4)...time(7) lost nanoseconds https://issues.jboss.org/browse/DBZ-1688[DBZ-1688]
* Support boolean as default for INT(1) column in MySQL https://issues.jboss.org/browse/DBZ-1689[DBZ-1689]
* SIGNAL statement is not recognized by DDL parser https://issues.jboss.org/browse/DBZ-1691[DBZ-1691]
* When using in embedded mode MYSQL connector fails https://issues.jboss.org/browse/DBZ-1693[DBZ-1693]
* MySQL connector fails to parse trigger DDL https://issues.jboss.org/browse/DBZ-1699[DBZ-1699]

=== Other changes

This release includes also other changes:

* Update outbox routing example https://issues.jboss.org/browse/DBZ-1673[DBZ-1673]
* Add option to JSON change event SerDe for ignoring unknown properties https://issues.jboss.org/browse/DBZ-1703[DBZ-1703]
* Update debezium/awestruct image to use Antora 2.3 alpha 2 https://issues.jboss.org/browse/DBZ-1713[DBZ-1713]

= Release Notes for Debezium 1.1
:awestruct-layout: doc
:awestruct-documentation_version: "1.1"
:toc:
:toc-placement: macro
:toclevels: 1
:sectanchors:
:linkattrs:
:icons: font

All notable changes for Debezium releases are documented in this file.
Release numbers follow http://semver.org[Semantic Versioning].

toc::[]

[[release-1.1.0-alpha1]]
== *Release 1.1.0.Alpha1* _(January 16th, 2020)_

See the https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12317320&version=12344080[complete list of issues].

=== Kafka compatibility

This release has been built against Kafka Connect 2.4.0 and has been tested with version 2.4.0 of the Kafka brokers.
See the https://kafka.apache.org/documentation/#upgrade[Kafka documentation] for compatibility with other versions of Kafka brokers.

=== Upgrading

Before upgrading the MySQL, MongoDB, PostgreSQL or SQL Server connectors, be sure to check the backward-incompatible changes that have been made since the release you were using.

When you decide to upgrade one of these connectors to 1.1.0.Alpha1 from any of the earlier 1.1.x, 1.0.x, 0.10.x, 0.9.x, 0.8.x, 0.7.x, 0.6.x, 0.5.x, 0.4.x, 0.3.x, 0.2.x, or 0.1.x versions,
first check the upgrading notes for the version you're using.
Gracefully stop the running connector, remove the old plugin files, install the 1.1.0.Alpha1 plugin files, and restart the connector using the same configuration.
Upon restart, the 1.1.0.Alpha1 connectors will continue where the previous connector left off.
As one might expect, all change events previously written to Kafka by the old connector will not be modified.

If you are using our docker images then do not forget to pull them fresh from Docker registry.

=== Breaking changes

When using the outbox event routing SMT and configuring a column from which to obtain the Kafka record timestamp from (table.field.event.timestamp option), then that value could have been exported as milliseconds, microseconds or nanoseconds, based on the source column's definition.
As of this release, the timestamp always be exported as milliseconds (https://issues.jboss.org/browse/DBZ-1707[DBZ-1707]).

The deprecated Postgres connector option `slot.drop_on_stop` has been removed; use `slot.drop.on.stop` instead (https://issues.jboss.org/browse/DBZ-1600[DBZ-1600]).

=== New Features

* MongoDB authentication against non-admin authsource https://issues.jboss.org/browse/DBZ-1168[DBZ-1168]
* Oracle: Add support for different representations of "NUMBER" Data Type https://issues.jboss.org/browse/DBZ-1552[DBZ-1552]
* Update Mongo Java driver to version 3.12.0 https://issues.jboss.org/browse/DBZ-1690[DBZ-1690]
* Support exporting change events in "CloudEvents" format https://issues.jboss.org/browse/DBZ-1292[DBZ-1292]
* Build Quarkus extension facilitating implementations of the outbox pattern https://issues.jboss.org/browse/DBZ-1478[DBZ-1478]
* Support column masking option for Postgres https://issues.jboss.org/browse/DBZ-1685[DBZ-1685]

=== Fixes

This release includes the following fixes:

* Make slot creation in PostgreSQL more resilient https://issues.jboss.org/browse/DBZ-1684[DBZ-1684]
* SQLserver type time(4)...time(7) lost nanoseconds https://issues.jboss.org/browse/DBZ-1688[DBZ-1688]
* Support boolean as default for INT(1) column in MySQL https://issues.jboss.org/browse/DBZ-1689[DBZ-1689]
* SIGNAL statement is not recognized by DDL parser https://issues.jboss.org/browse/DBZ-1691[DBZ-1691]
* When using in embedded mode MYSQL connector fails https://issues.jboss.org/browse/DBZ-1693[DBZ-1693]
* MySQL connector fails to parse trigger DDL https://issues.jboss.org/browse/DBZ-1699[DBZ-1699]

=== Other changes

This release includes also other changes:

* Update outbox routing example https://issues.jboss.org/browse/DBZ-1673[DBZ-1673]
* Add option to JSON change event SerDe for ignoring unknown properties https://issues.jboss.org/browse/DBZ-1703[DBZ-1703]
* Update debezium/awestruct image to use Antora 2.3 alpha 2 https://issues.jboss.org/browse/DBZ-1713[DBZ-1713]


add 4.2 deprecation note - snapshots

add 4.2 deprecation note - snapshots

[id="persistent-storage-snapshots"]
= Persistent storage using volume snapshots
include::modules/common-attributes.adoc[]
:context: persistent-storage-snapshots

toc::[]

[IMPORTANT]
====
Volume snapshot is deprecated in {product-title} 4.2.
====

This document describes how to use VolumeSnapshots to protect against data loss in {product-title}. Familiarity with xref:../../storage/understanding-persistent-storage.adoc#persistent-volumes_understanding-persistent-storage[persistent volumes] is suggested.

:FeatureName: Volume snapshot

include::modules/technology-preview.adoc[leveloffset=+0]

include::modules/persistent-storage-snapshots-about.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-controller-provisioner.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-starting-controller-provisioner.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-controller-provisioner-aws-gce.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-managing-users.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-creating-deleting.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-create.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-restore.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-delete.adoc[leveloffset=+2]

[id="persistent-storage-snapshots"]
= Persistent storage using volume snapshots
include::modules/common-attributes.adoc[]
:context: persistent-storage-snapshots

toc::[]

This document describes how to use VolumeSnapshots to protect against data loss in {product-title}. Familiarity with xref:../../storage/understanding-persistent-storage.adoc#persistent-volumes_understanding-persistent-storage[persistent volumes] is suggested.

:FeatureName: Volume snapshot

include::modules/technology-preview.adoc[leveloffset=+0]

include::modules/persistent-storage-snapshots-about.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-controller-provisioner.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-starting-controller-provisioner.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-controller-provisioner-aws-gce.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-managing-users.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-creating-deleting.adoc[leveloffset=+1]

include::modules/persistent-storage-snapshots-create.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-restore.adoc[leveloffset=+2]

include::modules/persistent-storage-snapshots-delete.adoc[leveloffset=+2]