Related problem

No response

Suggested solution

Strimzi supports multi-version single step upgrade, however downgrades must be handled step by step ensuring the 'to' Strimzi version in each step supports the current Kafka version.
During downgrade an attempt is made to read the Kafka information for the 'from' Kafka version by the 'to' version of the operator. When the 'from' Kafka version is not supported by the 'to' Strimzi version an error will be thrown because the version is unknown. Information such as the metadata version, interbroker protocol message format, log message format version are read from kafka-versions.yaml during the creation of a KafkaVersion object to represent the 'from' kafka version and the error message is generated as it cannot find the information for the unknown version.

However, while this information is important to know for the 'to' version and in upgrade for the 'from' version, it is not important for the 'from' version in the downgrade. Therefore it is possible to support multi-version single step downgrade by simply adding handling to not throw an exception when the 'from' version is not known in a downgrade.

I would like to propose to introduce the necessary handling for encountering an unknown version in downgrade in order to enable single step multi version downgrade for KRaft based clusters.

The downgrade support shall be subject to the limitations of Kafka downgrade, in particular related to the limited support for metadata version downgrade.

Alternatives

No response

Additional context

See proposal for further details