Closed erikgb closed 3 years ago
@domenicbove I am not sure what do to with this issue? Close it? I am more interested in desired state upgrade/downgrade (https://github.com/confluentinc/cp-ansible/issues/591), and do not care that much about the upgrade playbooks. 😊 But I think it can be possible to redesign the upgrade playbooks for customers that are ignorant to the broker properties inter.broker.protocol.version
and log.message.format.version
- based on the result of https://github.com/confluentinc/cp-ansible/pull/611. But I prefer to be in charge of those important broker properties.....
After https://github.com/confluentinc/cp-ansible/pull/611, I have now successfully upgraded from CP 5.5 to CP 6.1 just using the desired state upgrade/downgrade added to the 6.1.x
branch. Working like a charm, I am suggesting to deprecate and eventually remove the upgrade playbooks, and advice users of cp-ansible to just use their inventory and the desired state playbooks.
If this is supported by the community, the upgrade documentation will need to be rewritten, so here sharing my notes on how we upgraded. With reference to Apache Kafka upgrading docs:
inter.broker.protocol.version
and log.message.format.version
properties according to CURRENT_KAFKA_VERSION
. Note: This is the upstream Apache Kafka version, and not CP version. This is very important for (at least) two reasons:
kafka_broker_custom_properties:
inter.broker.protocol.version: <CURRENT_KAFKA_VERSION>
log.message.format.version: <CURRENT_KAFKA_VERSION>
NEXT_CP_VERSION
branch of cp-ansible for any variable changes and/or changed semantics of variables. In case a variable has changed name, you should probably duplicate the variable temporary, to be prepared for a possible emergency rollback/downgrade.deployment_strategy: serial
NEXT_CP_VERSION
branch of cp-ansible. Note: It is strongly recommended to first run your playbook in Ansible check mode, and preferably with diff mode enabled. The latter will allow you to verify that your configuration is picked up correctly and display (most of) the actual changes that is going to be performed to your cluster.inter.broker.protocol.version
broker property to the newer version, and run the desired state playbook once more.
We decided to postpone this, to keep an open door for a smooth possible rollback/downgrade.log.message.format.version
broker property to the newer version, and run the desired state playbook once more. Note: Changing the log.message.format.version
broker property to the newer version represents the point-of-no-return, so ensure that there is no need to roll back!
We decided to postpone this, to keep an open door for a smooth possible rollback/downgrade. Closing with the merge of 676
UPDATE: I have changed my suggestion on this issue, see https://github.com/confluentinc/cp-ansible/issues/588#issuecomment-814289884, but keeping the original description for reference.
Upgrade Kafka Broker should be idempotent and not restart brokers when system already has desired state.
Describe the issue We are trying to extend our Kafka GitOps approach with support for upgrades, with reference to the Upgrade Confluent Platform with Ansible Playbooks documentation. Trying to upgrade from CP 6.0 to CP 6.1. So far we completed step 1. (Upgrade Zookeeper) and step 2. (Upgrade Kafka), and the actual upgrade (first run) went well.
But it seems like the playbook
upgrade_kafka_broker.yml
is not idempotent - at least not the idempotence I am expecting. Even if the end result is the same after subsequent runs, all the brokers are unfortunately restarted on every single run. And this is far from optimal. Do you think it can be fixed?To Reproduce Run the upgrade of Zookeepers and Kafka Brokers at least twice:
Expected behaviour No tasks marked as changed on 2. (and subsequent) runs - including no broker restarts.
Inventory File Can provide additional information if needed.
Logs Can provide additional information if needed.
Environment (please complete the following information):
Additional context Can provide additional information if needed.