[labrenbe]

Description

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

[maltesander]

We have proper ClusterConditions https://github.com/stackabletech/operator-rs/blob/main/crates/stackable-operator/src/status/condition/mod.rs#L90 that might be reused or made generic to add custom condition type / etc.?

[labrenbe]

I believe this definitely makes sense and I considered using the utility around ClusterCondition but it would require a larger refactor which I didn't want to do in this PR.

[xeniape]

Question regarding a specific scenario: I guess it would be possible for someone to create a KafkaTopic object with a Kafka topic they theoretically shouldn't have permissions for and then just delete that object, in turn deleting that Kafka topic in the cluster. Would that be covered with authorization somehow? That scenario would be relevant for different user groups managing different topics in the same cluster but I think Kafka has also some system topics?

[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.