spec.additionalMetadata merges user labels/annotations onto every object the operator creates. For the per-member objects (member Pods, data PVCs, EtcdMember CRs) that happens on each object's creation, so an edit lands naturally as members are replaced. For the cluster-scoped objects it never lands: the PDB and both Services are created once and live for the cluster's whole lifetime, and applyAdditionalMetadata is only called in their IsNotFound branches.
controllers/etcdcluster_controller.go:1548 — reconcilePDB applies the metadata only when creating the PDB. The update path below it compares minAvailable / maxUnavailable and returns early when they match (controllers/etcdcluster_controller.go:1574-1580), so labels and annotations are never revisited.controllers/etcdcluster_controller.go:1851 — ensureService has the same shape: metadata on create, and the drift reconcile below it covers spec fields only.
Effect: adding or changing a key under spec.additionalMetadata on a running cluster applies to member Pods as they roll, but never to that cluster's PDB or its <cluster> / <cluster>-client Services. The objects stay inconsistent with each other indefinitely, and the only way to converge them is to delete the object and let the operator recreate it. That is easy to hit with the common case of adding a cost-allocation or ownership label to an existing cluster.
README.md:26 describes the field as "All three apply on object creation and are latched like the rest of the spec", which is literally accurate but reads as "applies to objects created from now on" rather than "never applies to these three objects". Either the behaviour or the wording should change.
Worth settling as part of the fix: whether this metadata should be reconciled on update at all. ensureService already documents that admission webhooks routinely inject annotations onto Services and that the operator deliberately does not fight them, so a blind overwrite of the whole annotation map would be a regression. Merging only the keys that spec.additionalMetadata currently declares, and removing only the ones it previously declared, would preserve that property — which implies tracking the previously-applied key set somewhere.
spec.additionalMetadatamerges user labels/annotations onto every object the operator creates. For the per-member objects (member Pods, data PVCs,EtcdMemberCRs) that happens on each object's creation, so an edit lands naturally as members are replaced. For the cluster-scoped objects it never lands: the PDB and both Services are created once and live for the cluster's whole lifetime, andapplyAdditionalMetadatais only called in theirIsNotFoundbranches.controllers/etcdcluster_controller.go:1548—reconcilePDBapplies the metadata only when creating the PDB. The update path below it comparesminAvailable/maxUnavailableand returns early when they match (controllers/etcdcluster_controller.go:1574-1580), so labels and annotations are never revisited.controllers/etcdcluster_controller.go:1851—ensureServicehas the same shape: metadata on create, and the drift reconcile below it covers spec fields only.Effect: adding or changing a key under
spec.additionalMetadataon a running cluster applies to member Pods as they roll, but never to that cluster's PDB or its<cluster>/<cluster>-clientServices. The objects stay inconsistent with each other indefinitely, and the only way to converge them is to delete the object and let the operator recreate it. That is easy to hit with the common case of adding a cost-allocation or ownership label to an existing cluster.README.md:26describes the field as "All three apply on object creation and are latched like the rest of the spec", which is literally accurate but reads as "applies to objects created from now on" rather than "never applies to these three objects". Either the behaviour or the wording should change.Worth settling as part of the fix: whether this metadata should be reconciled on update at all.
ensureServicealready documents that admission webhooks routinely inject annotations onto Services and that the operator deliberately does not fight them, so a blind overwrite of the whole annotation map would be a regression. Merging only the keys thatspec.additionalMetadatacurrently declares, and removing only the ones it previously declared, would preserve that property — which implies tracking the previously-applied key set somewhere.