-
Bug
-
Resolution: Done
-
Major
-
1.2.0.GA, 1.3.0.GA, 1.4.0.GA
-
None
The StorageDiff class is handling the blocking of unsupported changes to storage configuration. It allows only changes to things such as volume and delete claim or eventually adding and removing JBOD volumes. This works well.
But when the user scales the cluster (either Kafka or Zookeeper) up or down, he will logically want to do two different things:
- add overrides for the newly added brokers / nodes
- remove the overrides for the brokers which were just scaled down from the cluster
And the StorageDiff sees this as a change which is not allowed and blocks it. The tricky thing here is that removing or adding overrides for existing nodes should not be allowed. However we should probably allow it for removed nodes or new nodes. So we might need to add support to let users deal with this without overriding the annotations with the storage configuration.
However, especially for scale-up it will be probably non-trivial to understand where these can be added and when they cannot be added anymore as we will need the information about the current as well as desired nodes. Should we add the old number of nodes to Status?
To better understand the scenario, imagine deployment like this:
apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
version: 2.2.1
replicas: 3
listeners:
plain: {}
tls: {}
config:
offsets.topic.replication.factor: 3
transaction.state.log.replication.factor: 3
transaction.state.log.min.isr: 2
log.message.format.version: "2.2"
storage:
type: jbod
volumes:
- id: 0
type: persistent-claim
size: 100Gi
deleteClaim: true
class: gp2
overrides:
- broker: 0
class: gp2-a
- broker: 1
class: gp2-b
- broker: 2
class: gp2-c
- broker: 3
class: gp2-a
- broker: 4
class: gp2-b
zookeeper:
replicas: 3
storage:
type: persistent-claim
size: 100Gi
deleteClaim: false
class: gp2
overrides:
- broker: 0
class: gp2-a
- broker: 1
class: gp2-b
- broker: 2
class: gp2-c
- broker: 3
class: gp2-a
- broker: 4
class: gp2-b
entityOperator:
topicOperator: {}
userOperator: {}
Deploy it and scale down the Zookeeper and Broker nodes to 3 and remove the overrides whcih will not be useful anymore for nodes 3 and 4.