Add support for additional labels and annotations to be propagated to all pods about operator HOT 7 CLOSED

Yeah I guess wedging those in isn't "too" bad. So it sounds like we can agree on the #1099 (comment) as the structure.
I'd also be in favor of error if trying to override one of our default labels.
I'm willing to review if someone is interested in submitting a PR.

from operator.

I'm in agreement that the operator should error if the user tries to override a default label set by the operator; that should be sufficient for most use cases to start off with.

from operator.

Hey @Chili-Man,

We've put up an outline of proposed changes to operator component configuration. Among other fields, this will include allowing custom labels and annotations. Please take a look. We'd appreciate your input on the proposed changes: #1990

from operator.

Sorry we missed this request and took so long to respond. This seems like a reasonable request. I'm not sure of the behavior we would want when operator is already setting an annotation or label and the user provided the same one. I'm not sure if one should take precedence or if it should result in reporting degraded in tigerastatus.

Your proposal follows the pattern we started with componentResources but I'm not sure I like the pattern we started. I think I like the following better. I'd possibly even consider adding podResources and deprecating componentResources in the future.

componentMeta:
  - name: Typha
    podAnnotations: ....
    podLabels: ...

@caseydavenport WDYT?

I'm not sure of the best way to handle this, does anyone have any good examples of how others handled this? I think I've seen others allow the whole podTemplate be defined but I think we want to keep this operator more opinionated than that, so I don't think that is an option.

from operator.

@tmjd what's the problem you have with componentResources? Agree it has "Resource" in the name, which is a bit confusing, but I think we could probably just wedge these into that structure and redefine it a bit.

// The ComponentResource struct associates pod configurations with a particular named component.
type ComponentResource struct {
	// ComponentName is an enum which identifies the component
	// +kubebuilder:validation:Enum=Node;Typha;KubeControllers
	ComponentName ComponentName `json:"componentName"`
	// ResourceRequirements allows customization of limits and requests for compute resources such as cpu and memory.
	ResourceRequirements *v1.ResourceRequirements `json:"resourceRequirements"`
        // Labels allow setting labels on this component.
        Labels map[string]string `json:"labels"`
        // Annotations allows setting annotations on this component
        Annotations map[string]string `json:"annotations"`
}

We could always deprecate in the future and rename this to something else if the name is the main issue. "Resource" is generic enough to mean anything - i.e., "This structure is a resource from which component-specific data can be found"

from operator.

As for the conflicting problem, the "safest" thing to do would be to warn / error if a user tried to override one of our default labels and ignore that label. We can also always relax that restriction down the line if needed, whereas it's much harder (read: impossible) to close that box once it's open.

from operator.

With #2063 merged it is now possible to add custom labels and annotations to the core Calico components.

from operator.