-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers #6917
Conversation
Signed-off-by: lou <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #6917 +/- ##
==========================================
+ Coverage 60.69% 61.11% +0.41%
==========================================
Files 249 255 +6
Lines 26493 27072 +579
==========================================
+ Hits 16081 16545 +464
- Misses 9268 9348 +80
- Partials 1144 1179 +35
|
Signed-off-by: lou <[email protected]>
Signed-off-by: lou <[email protected]>
Signed-off-by: lou <[email protected]>
@27149chen can you also please get patch code coverage to 60% |
Signed-off-by: lou <[email protected]>
Signed-off-by: lou <[email protected]>
Signed-off-by: lou <[email protected]>
done |
namespaceInclusion := collections.NewIncludesExcludes().Includes(r.Conditions.Namespaces...) | ||
if !namespaceInclusion.ShouldInclude(obj.GetNamespace()) { | ||
return nil | ||
} | ||
|
||
if r.Conditions.GroupResource != groupResource { | ||
g, err := glob.Compile(r.Conditions.GroupResource) |
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.
one thing came in my mind
if we support globbing with namespace filter.
Scenario -> user provided NS filter, with path glob as blah*
Now blah* can contain both cluster scope and namespaced scope CRs.
We need to make it clear in docs that if user wants to do cluster scope they have to put NS filter as empty otherwise it won't work
and using it in conjunction with GroupResource glob path will have these further nuances.
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.
- we do support namespace glob
- if user enters
namespaces: ["blah*"]
, only namespaced resources in namespace started with blah will be matched
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.
yeah
again the limitation is cluster scope won't be taken care of
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.
sorry, not quite understand, can you give an example?
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.
user provided NS filter (default), with GroupResource glob as blah*
Now blah* can contain both cluster scope and namespaced scope CRs.
We need to make it clear in docs that if user wants to do cluster scope they have to put NS filter as empty otherwise it won't work
and using it in conjunction with GroupResource glob path will have these further nuances.
Reworded my initial comment to make it more clear
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.
" I think including the cluster resources by default is reasonable"
I feel this would lead to changes which are not intended.
I am worried about this.
In terms of REAL filters here - similar to what we have in backup /restore - includeClusterSCopeResources
We can add a bool for that.
that would make it consistent and give control to user.
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 is only useful for globbed patterns
but would lead to confusion if explicit GroupResource is mentioned.
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.
On further thought, I think it's fine.
But PLEASE just add this behaviour of cluster scope by default to docuemtnation.
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.
Just to reiterate, I am fine with current changes you have. Just that I request you to document the behaviour of cluster scope by default in case of globbed GroupResourcce.
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.
thanks, updated
Signed-off-by: lou <[email protected]>
@ywk253100 I am done with my review |
I'm good for the changes. |
Signed-off-by: lou <[email protected]>
done |
namespaceInclusion := collections.NewIncludesExcludes().Includes(r.Conditions.Namespaces...) | ||
if !namespaceInclusion.ShouldInclude(obj.GetNamespace()) { | ||
return nil | ||
} | ||
|
||
if r.Conditions.GroupResource != groupResource { | ||
g, err := glob.Compile(r.Conditions.GroupResource) |
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.
Hey I am not sure if ignoring ns filter is the right way
I am wondering if we should add another flag which says includeClusterSCope
similar to what we have in backup/restore APIs.
- The above configmap will apply the Merge Patch to all the pods in namespace ns1 and remove the annotation `foo` from the pods. | ||
- Both json and yaml format are supported for the patchData. | ||
|
||
#### Strategic Merge Patch |
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.
we should perhaps move these 2 sections above
this is currently below jsonpatch examples and adbacned scenarios.
We should probably refactor this whole doc to make things more clear.
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.
we can refactor it later, I don't want to do it in this pr
} | ||
} | ||
``` | ||
- The above configmap will apply the Merge Patch to all the pods in namespace ns1 and remove the annotation `foo` from the pods. |
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.
add links to kubectl merge patch docs / other docs for reference. YOU can even provide sample kubectl command for use to test out in local setup before creating CM.
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.
added doc link
Signed-off-by: lou <[email protected]>
Hey I am not sure if ignoring ns filter is the right way |
Signed-off-by: lou <[email protected]>
support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers
support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers Signed-off-by: lou <[email protected]>
Cherry-pick #6917 to release 1.12
Please add a summary of your change
Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers, implement #6797
Does your change fix a particular issue?
Fixes #6728
Please indicate you've done the following:
/kind changelog-not-required
as a comment on this pull request.site/content/docs/main
.