maxsmythe
commented
2 years ago Thanks for the use case!
This sounds a bit to me like it could be addressed by the features mentioned in #1348 though an interesting feature of this request is that it also seeks to avoid boilerplate.
if multi-mutators and stamped mutators went together such that you could essentially write a base mutator and then add customizations (the below just describes the logic flow, not what the actual resource would look like):
- base:
location=metadata.labels,mutator=AssignMetadata,match=<match against all pods> - modifications:
- locationSuffix=label1, value=Value1
- locationSuffix=label2, value=value2
- etc...
This should be a similar level of boilerplate, but has the advantage of not needing to hardcode in special logic for merging labels, which may make it more flexible in terms of handling other, similar use-cases (like containers + initContainers) and accommodating as K8s adds more features in the future.
stale[bot]
We have a use case where pods are created with a single label that is a reference to an ID in another system. We want to take data from that system (based on that ID) and add several (1-20 labels) to the pods. Currently, it seems that the AssignMetadata mutating CRD allows only a single label to be set at a time. It seems suboptimal to manage that many resources for a single pod/deployment. We'd like to describe a set of labels in a single resource.
Currently the AssignMetadata mutation ignores labels that already exist on the pod. One options might be allowing
location: metadata.labels, and settingproperties.assign.valueto a mapping oflabel: valuepairs (similar to the last example in the mutation docs, for Assign). The controller could still silently ignore changes to existing labels as it currently does for single changes.