-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove networkpolicy from commonlabel defaults #1
base: master
Are you sure you want to change the base?
Conversation
If we apply commonLabels to the spec of a networkpolicy it will alter the policy so it no longer matchs what was applied.
@@ -144,19 +144,4 @@ commonLabels: | |||
create: false | |||
group: policy | |||
kind: PodDisruptionBudget | |||
|
|||
- path: spec/podSelector/matchLabels |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should still be allowed, no? It's referencing resources in the namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's still allowed just not the default behaviour.
Open issue: kubernetes-sigs#1009 This is a likely breaking change that will be hard to merge back upstream. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@switj If we're going to run a fork of kustomize for applying the clusters, can you update the instructions on how one can get the fork? For normal apps we'd want to keep using the regular kustomize.
Otherwise if this is the only way to go I'm good with the change.
What is the alternative to forking kustomize? What is the impact. I do worry about forking and maintaining such a thing. |
If we apply commonLabels to the spec of a networkpolicy it will alter
the policy so it no longer matchs what was applied.