You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the namespace supplied in spec.targetNamespace is created and modified by the operator but there does not seem to be any dials for augmenting labels/annotations.
Would be nice to have both the ability to augment attributes of the namespace (labels/annotations), including ones that are included by the operator to date, and the ability to disable namespace creation/management by the operator to have it use a "provided" namespace
Use case
Our cluster expectations is that all pods are members of the linkerd service mesh, and we have specified running-in-environment-with-injected-sidecars = true
linkerd has two modes of running, either with a cni plugin or via an init container that modifies ip tables. The later is incompatible with the label pod-security.kubernetes.io/enforce: restricted that the operator adds on this namespace. There are also other annotations like linkerd.io/inject: enabled that would be nice to specify at the namespace level.
In other contexts i think its desirable to have that namespace created ahead of tekton pipelines being deployed into it. One case i can think of is addition of quota management or other namespaces governances that might be wanted ahead of having pipelines deployed into it to ensure that it follows the governances of that namespace
The text was updated successfully, but these errors were encountered:
@jkandasa yes, and/or allow for disabling namespace management in the operator so that the namespace must be created and managed externally to the operator
Feature request
the namespace supplied in
spec.targetNamespace
is created and modified by the operator but there does not seem to be any dials for augmenting labels/annotations.Would be nice to have both the ability to augment attributes of the namespace (labels/annotations), including ones that are included by the operator to date, and the ability to disable namespace creation/management by the operator to have it use a "provided" namespace
Use case
Our cluster expectations is that all pods are members of the linkerd service mesh, and we have specified
running-in-environment-with-injected-sidecars = true
linkerd has two modes of running, either with a cni plugin or via an init container that modifies ip tables. The later is incompatible with the label
pod-security.kubernetes.io/enforce: restricted
that the operator adds on this namespace. There are also other annotations likelinkerd.io/inject: enabled
that would be nice to specify at the namespace level.In other contexts i think its desirable to have that namespace created ahead of tekton pipelines being deployed into it. One case i can think of is addition of quota management or other namespaces governances that might be wanted ahead of having pipelines deployed into it to ensure that it follows the governances of that namespace
The text was updated successfully, but these errors were encountered: