Add patchMergeKey and patchStrategy support to OpenAPI #44121
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
This change is |
k8s-github-robot
added
size/M
mbohlool
added
release-note-none
| if len(extensions) == 0 { | ||
| return nil | ||
| } | ||
| g.Do("VendorExtensible: spec.VendorExtensible{\nExtensions: spec.Extensions{\n", nil) |
There was a problem hiding this comment.
This is not identical to before. If no extensions exist, this line should not present it the open api spec, right?
There was a problem hiding this comment.
right, I am checking that the line before. if len(extensions) is zero, then we just return without generating anything.
k8s-github-robot
added
size/L
mbohlool
force-pushed
the
patch
branch
2 times, most recently
from
eaafb90
to
fbbac5d
Compare
|
@k8s-bot verify test this |
mbohlool
added
release-note
|
LGTM, thanks! |
| tagExtensionPrefix = "x-kubernetes-" | ||
| tagPatchStrategy = "patchStrategy" | ||
| tagPatchMergeKey = "patchMergeKey" | ||
| patchStrategyExtensionKey = "x-kubernetes-patch-strategy" |
There was a problem hiding this comment.
Would it make sense to write this and below as tagExtensionPrefix + "patch-strategy"?
There was a problem hiding this comment.
I was doing it that way, but because we had patch-strategy and patchStrategy both, I though it could be mixed up and I am not sure about the naming of only "patch-strategy". Something like patchStrategyPartialExtensionKey? :)
| return "", nil | ||
| } | ||
| if len(tags) > 1 { | ||
| return "", fmt.Errorf("Multiple values is not allowed for tag %s", tag) |
| return nil | ||
| } | ||
|
|
||
| // TODO(#44005): Move this validation outside of this generator (probably to policy verifier |
| if err != nil { | ||
| return err | ||
| } | ||
| if patchMergeKeyStructTag != patchMergeKeyCommentTag { |
There was a problem hiding this comment.
It should be ok for it to not be set in the struct tag, correct? It's just that if both are present they must match?
There was a problem hiding this comment.
it is a good question @pwittrock and @ymqytw should know the answer too :)
There was a problem hiding this comment.
IMO we want always enforce they match, at least for now.
Otherwise, if the client move to use openapi someday and the server is still using the struct tags and they are inconsistent. Patch will do the wrong things.
| @@ -89,6 +89,8 @@ message ClusterSpec { | |||
| // This is to help clients reach servers in the most network-efficient way possible. | |||
| // Clients can use the appropriate server address as per the CIDR that they match. | |||
| // In case of multiple matches, clients should use the longest matching CIDR. | |||
| // +patchMergeKey=clientCIDR | |||
| // +patchStrategy=merge | |||
There was a problem hiding this comment.
Should these get copied here? I guess it doesn't hurt anything. The tags should really be stripped out by the proto generator, I guess that can be fixed in another PR.
There was a problem hiding this comment.
Yeah, looks like this isn't making it worse.
|
/approve nits can be fixed in a followup. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lavalamp, mbohlool
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
k8s-github-robot
added
the
approved
mbohlool
added
the
lgtm
|
@k8s-bot gci gce e2e test this |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue (batch tested with PRs 43777, 44121) |
Support generating Open API extensions for strategic merge patch tags in go struct tags
Support
patchStrategyandpatchMergeKey.Also support checking if the Open API extension and struct tags match.
cc: @pwittrock @ymqytw
(Description mostly copied from #43833)