Federico Valeri

@tombentley yes, it was the CO that was calling System.exit, not the TO. That said, every verticle can potentially call it. I see the point of crash safety and the...

Thanks. At least when doing so would skip optimizations that are likely to cause issues.

Hi @cthtrifork, thanks for raising this. It was decided to not provide this metric with UTO because it does not scale well (it's an additional metric for each managed topic)....

Hi @khartld, this is an interesting use case. Thanks for raising. We recently added an environment variable that allows to specify which topic configurations are reconciled (ALL by default), everything...

I was able to reproduce the issue: ```sh Reconciliation #9(upsert) KafkaTopic(test/rebalance-test): Config changes [AlterConfigOp{opType=DELETE, configEntry=ConfigEntry(name=leader.replication.throttled.replicas, value=null, source=UNKNOWN, isSensitive=false, isReadOnly=false, synonyms=[], type=UNKNOWN, documentation=null)}, AlterConfigOp{opType=DELETE, configEntry=ConfigEntry(name=follower.replication.throttled.replicas, value=null, source=UNKNOWN, isSensitive=false, isReadOnly=false, synonyms=[], type=UNKNOWN,...

Here the CO and TO reconciliations are a bit different. The former only reverts configuration changes that are different from `.spec.kafka.config`. Instead, the latter reverts configuration changes that are not...

I'm fine with introducing a new env var. Having something like `STRIMZI_IGNORED_TOPIC_CONFIG` could help to resolve this and similar race conditions. We already have a method called `skipNonAlterableConfigs` which could...

@khartld are you planning to work on this? Otherwise I can do it.

Ok, let's wait then.

> I'd be happy to implement it given a specification :) Sure, let's wait the next community meeting (May 2nd) to find an agreement on specs. > Another behavior question...