Allow objects to have custom labels about operator HOT 10 CLOSED

@tmjd I don't see any reason not to copy the labels in our merge logic the same way we do with annotations - am I missing something there?

Definitely agree about adding some conventional app labels as well.

from operator.

Hey all,

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

from operator.

If the possible solution is accepted by the maintainers, I can provide a PR for it.

from operator.

I think I'd like to see the operator updated to add the app.kubernetes.io/name since that is the root of why you are looking to merge labels on the namespace.
I think that label is the direction that k8s is moving so it would be good to make that change.
@caseydavenport WDYT? Is there any reason we wouldn't want to start including that new label?
I assume we'd keep the k8s-app we already have and add app.kubernetes.io/name.

from operator.

I think the operator adding the standard labels definetely makes sense and should be there.
I also think we should still give the ability for people to label the calico-system namespace.

In my case, I want to disable OPA for the calico namespace, it's good practice to disable OPA for core system namespace like kube-system. The calico namespace manages internal cluster networking which makes it very much a core namespace and could cause whole cluster failures if OPA starts denieing API requests for it. For instance, a misconfigured OPA policy could deny new calico-node pods to start up which would not be good.

from operator.

Is there any update about this issue? I am running into it in a similar use case. We label namespaces to enable and disable network policies. As we cannot label the namespace the calico-kube-controller to kube-api communication, ironically, is blocked by the network policies.

We have tried to pre-create the namespace, as well as adding the label on the fly, but it keeps disappearing (I assume that removed by the operator reconciliation cycle)

from operator.

I'm not aware of anyone currently working on this, although the change should be rather straightforward.

from operator.

Sorry I missed responding before to

@tmjd I don't see any reason not to copy the labels in our merge logic the same way we do with annotations - am I missing something there?

Yeah I don't know any reason to not do that. Sounds reasonable.

I also am not aware of anyone working on it.

from operator.

We would love this feature too please so that we can disable istio sidecar injection on the namespace

Thanks :)

from operator.

For posterity:

• This PR added the ability to kubectl label any object and have it not overwritten by the operator: #1680
• This PR allows users to set a variety of custom fields at install time: #2063

I'm going to close this for now - if there is a specific scenario not covered by those two, please open another issue and we'll track it there.

from operator.