[labrenbe]

Description

Part of stackabletech/issues#888.

Adds shared utilities required for stackabletech/kafka-operator#1028.

• labels and selectors for agents
• new enum for platform access with TLS

Depends on https://github.com/stackabletech/decisions/issues/98 and https://github.com/stackabletech/decisions/issues/99.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added

[xeniape]

Claude noted down some possible lifecycle problems/decisions:

• The managed object would need a finalizer on deletion, otherwise the object gets deleted right away and the agent might not have had enough time reading the specs of the object needed to execute deletion logic in the product. So the object might never get deleted. So the finalizer would be definitely needed.
• BUT with the finalizer another problem pops up: the deletion process might get stuck if there is no one removing that finalizer again. This can happen in different scenarios, for example someone could delete the product cluster or namespace and if the agent gets removed because of that before the deletion process is done and the finalizer removed, there is no one to remove that finalizer so the namespace deletion is stuck. So either the agent needs to stay alive until everything is processed or someone else (operator?) needs to release the objects

Not sure if this is part of this PR or not, but it seemed general enough to mention it in the operator-rs changes, if this provides some mechanism for all the operators.

[labrenbe]

Claude noted down some possible lifecycle problems/decisions:

* The managed object would need a finalizer on deletion, otherwise the object gets deleted right away and the agent might not have had enough time reading the specs of the object needed to execute deletion logic in the product. So the object might never get deleted. So the finalizer would be definitely needed.

* BUT with the finalizer another problem pops up: the deletion process might get stuck if there is no one removing that finalizer again. This can happen in different scenarios, for example someone could delete the product cluster or namespace and if the agent gets removed because of that before the deletion process is done and the finalizer removed, there is no one to remove that finalizer so the namespace deletion is stuck. So either the agent needs to stay alive until everything is processed or someone else (operator?) needs to release the objects

Not sure if this is part of this PR or not, but it seemed general enough to mention it in the operator-rs changes, if this provides some mechanism for all the operators.

Yes, the idea is to have the operator clean up after a KafkaCluster (or the whole Namespace) has been deleted and there is no agent left to clean up finalizers. As the cluster is being deleted anyway the operator only has to remove finalizers and doesn't need to take action in Kafka.

For me this logic is a candidate to extract into operator-rs in the future.

[Techassi]

The Clippy errors are a false-positive btw. Fixed in #1323.

Once this is approved, an admin can force-merge this.

[maltesander]

LGTM!

[maltesander]

LGTM!