Description

As a user of the Stackable Data Platform (SDP) I want to be able to override attributes of objects the SDP operators generate for me, similar to what the podOverride feature does but for more object types.

Value

Some environments need special annotations or labels to work e.g., AWS assumed identities and ServiceAccount annotations).
There are probably other corporate policy or workaround use-cases we don't know about yet and we want to enable them.

Tasks

• https://github.com/stackabletech/decisions/issues/64
• feat: Support objectOverrides operator-rs#1118
• Add objectOverrides concepts page documentation#807

Rollout to all operators

Phase 1: Investigation (timebox: 3 days max)

• Create inventory of all object types we currently generate across operators
• Research what other operators do (strimzi, cloud native pg etc.)
• Come up with 1-3 design approaches/ideas with pros/cons for each on how this could be implemented including rough estimates (days, weeks, months....)

Phase 2: Desing & ADR

Only if we decide to continue after phase 1

• Create a decision for the chosen approach
• Create an ADR with the outcome
• Decide on podOverride migration strategy if needed

Phase 3: Implementation

• feat: Support objectOverrides operator-rs#1118

• TEMPLATE: feat: Support objectOverrides druid-operator#782

• feat: Support objectOverrides  airflow-operator#726

• feat: Support objectOverrides trino-operator#831

• feat: Support objectOverrides hbase-operator#725

• feat: Support objectOverrides hdfs-operator#741

• feat: Support objectOverrides hive-operator#665

• feat: Support objectOverrides kafka-operator#927

• feat: Support objectOverrides nifi-operator#885

• feat: Support objectOverrides opensearch-operator#93

• feat: Support objectOverrides spark-k8s-operator#640

• feat: Support objectOverrides superset-operator#693

• feat: Support objectOverrides zookeeper-operator#987

• feat: Support objectOverrides opa-operator#795

• feat!: Add objectOverrides field to ListenerSpec operator-rs#1136

• feat: Support objectOverrides listener-operator#364

• Support serviceOverrides on the Listener:

• feat!: Add ListenerClass.spec.serviceOverrides field operator-rs#1142

• feat: Support serviceOverrides on the ListenerClass listener-operator#365

• Design what exactly should be configurable and how the CRD structure should look like (Decision/ADR)

  • This should include a research phase into what other operators are doing

• Decide whether to migrate podOverrides into this potentially more generic feature or whether to keep them

• Add subtasks to this issue for the implementation part

• Implement & document

Research outcome

List of objects created is hopefully everything that implements the ClusterResource trait:

• ConfigMap
• Secret
• Service
• ServiceAccount
• RoleBinding
• PodDisruptionBudget
• Listener
• Job
• StatefulSet
• DaemonSet
• Deployment

Acceptance Criteria

• Users can override spec and metadata of all objects we generate (don't forget about the StatefulSet)
• Users have documentation and examples on how to add labels & annotations to all objects we create
• This does not mean we can only override labels & annotations but those have come up in the past
• Write concepts page
• Link to concepts page in CRD docs

Release Notes

Added

• Support objectOverrides, a list of generic Kubernetes objects, which are merged into the objects created by the operator (e.g. StatefulSets, Listeners or ConfigMaps).
  Have a look at the concepts page for details.
  The priority of the overrides (in ascending order) is configOverrides -> podOverrides -> objectOverrides, with the latter overriding the previous.

References

• Internal: SUP-153, SUP-237
• Add user configurable labels to our crds which operators pass through to all created objects #184