[Bug]: strimzi kafka custom resource reverting to defaults about strimzi-kafka-operator HOT 8 CLOSED

Strimzi never updates the Kafka custom resource metadata or specification. Only the status subresource. So if the changes are reverted, you have to look at your infrastructure and tooling to find out what is causing the issue. Maybe the resource is managed through some GitOps tooling or something and you have to apply the change there at the source? I think this should be closed and we should continue with the discussion you already started.

from strimzi-kafka-operator.

It's not managed by anything, no. It is a directly applied manifest which is not tied to our deploy system at all, nor have we done any deploys or even commits to the repository where the manifests live. There's nothing that touches this outside of human fingers, we have two people that have access including myself and neither touched it.

The reconciliation steps that the strimzi operator is mentioning are certainly interacting with the kafka custom resource.

Is there any way in the operator or kafka custom resource that we can update the defaults to reflect our changes? The 100Gb disk size for instance, that must be set somewhere, I presume it to be the default.

Namespace events would be the only potential tracking of this that I'm aware of and unless I happen to catch it those rotate out after an hour.

from strimzi-kafka-operator.

There is no place in the code that updates the Kafka resource spec or metadata. Feel free to look for it in the source code if you want. I do not know what your environment looks like, what tools you use or don't use, or who has access to it. But it is not Strimzi reverting your changes. The steps you describe are not reproducible in other environments.

from strimzi-kafka-operator.

Can you tell me how the operator knows what defaults to use when creating the kafka custom resource in the first place? Where does it get this from, for disk size on the jdb type and for what custom configs exist in .spec.kafka.config?

It'd be a bandage for us but if we couple update the source of this to have our own custom defaults then this would at least cause these instances to work correctly while we try to figure out what is changing things.

Again last night, when nothing was running, zero deployments, zero commits at all, zero manipulative services within K8s or outside of it, the kafka resource is now one generation higher at 13 and we've again lost our custom log retention setting from the kafka boxes.

from strimzi-kafka-operator.

There is no default storage size. There is no default value for .spec.kafka.config. The storage size is mandatory. The .spec.kafka.config is optional and if you don't specify it, you don't specify it. Once again, Strimzi does not overwrite your resource with any defaults.

from strimzi-kafka-operator.

So in a new setup, if I apply the operator and do whatever needs to be done, I would have to specify a disk size when it creates the initial kafka custom resource? The Strimzi operator I assume does that initial creation, no?

Or is it just a yaml manifest that is applied by the creating user and strimzi is only aware of it by the strimzi.io/cluster label?

from strimzi-kafka-operator.

Yes. You have to specify the disk size in the Kafka CR. Strimzi will use that to create the PVCs, so you do not need to create those. But the size will be the one you specified in the Kafka CR.

from strimzi-kafka-operator.

Ok, that original manifest is nowhere to be found so mystery remains. I'll close this off then and keep investigating.

from strimzi-kafka-operator.