csviri opened a new pull request, #1192:
URL: https://github.com/apache/flink-kubernetes-operator/pull/1192
## What is the purpose of the change
This pull request adds a new operator config option
`kubernetes.operator.events.labels` that attaches a fixed set of labels to the
metadata of every Kubernetes event created by the operator.
Operator-generated events are currently indistinguishable from other
events in a namespace via label selectors. Common labels let cluster tooling
(event exporters, alerting, retention policies, dashboards) filter and route
operator events without parsing their contents.
```yaml
kubernetes.operator.events.labels: env:prod,owner:flink
```
The option is read once at operator startup, so changing it requires an
operator restart.
## Brief change log
- New `OPERATOR_EVENT_LABELS` map option (default empty) in
`KubernetesOperatorConfigOptions`, documented in the advanced section;
generated config docs regenerated
- `EventRecorder` holds the configured labels as `commonLabels` and
applies them on all event creation paths; new `EventRecorder.create(client,
listeners, operatorConfig)` factory, with the existing two-arg overload
defaulting to an empty config
- `EventUtils.createIfNotExists` and `EventUtils.createWithAnnotations`
gained a `labels` parameter so labels reach the paths that previously ignored
them; the old signatures are kept as overloads that pass no labels
- Configured labels are merged with caller-provided labels, with the
caller winning on conflicting keys, so configuring e.g. `parallelismMap` cannot
break autoscaler scaling report dedupe
- Label entries Kubernetes would reject are dropped with a `WARN` at
startup — `setLabels` replaces the whole label map, so a single invalid entry
would otherwise fail creation of every event. Keys reuse
`K8sAnnotationsSanitizer.isValidAnnotationKey` (same syntax as annotation
keys); new `isValidLabelValue` covers the value rules (empty, or ≤63 chars,
alphanumeric start/end, `-_.` in between)
- `EventUtils.setLabels` defensively copies the map before setting it;
parameter renamed `existing` → `event` since it is now also used on freshly
built events
- `FlinkOperator` passes the initialized `this.client` field (the
constructor parameter is null outside of tests) and the base config to
`EventRecorder.create`
Behaviour is unchanged when the option is unset: paths that previously set
no labels still set none, and autoscaler dedupe labels are unaffected.
One deliberate subtlety: paths that do not set their own dedupe labels
pass the (possibly empty) common label map rather than `null`. Because labels
are replaced on every update, passing the map is what clears a previous
update's dedupe labels — the autoscaler relies on this to re-emit a
scaling report within the dedupe interval after switching back to scaling
enabled mode. This is documented on the `commonLabels` field.
## Verifying this change
This change added tests and can be verified as follows:
- Added `EventRecorderTest` (mock Kubernetes client) covering: no labels
on events by default; configured labels applied on events created via
`createOrUpdateEventWithInterval`, `createIfNotExists` and
`createWithAnnotations`; labels preserved when an existing event is
updated (count incremented); caller labels merged over configured ones with
caller precedence; no labels set on the legacy paths when the option is unset
- Added `K8sAnnotationsSanitizerTest#testIsValidLabelValue` covering
empty, max-length and boundary values plus rejection cases (spaces,
leading/trailing `-` and `.`, `@`, `/`, >63 chars, null)
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changes to the
`CustomResourceDescriptors`: no
- Core observer or reconciler logic that is regularly executed: no
(event creation is touched, but with no behaviour change when the option is
unset)
## Documentation
- Does this pull request introduce a new feature? yes
- If yes, how is the feature documented? docs (generated config option
reference) and JavaDocs
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Opus 5)
Two notes before you post:
- I have not run mvn clean verify in this session, so the "change passes
automated tests" checklist item is unverified.
- Fill in the actual AI tooling line yourself — I filled it in based on
this session, but only you know how much of the code was authored that way. If
none was, uncheck it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
