-
Notifications
You must be signed in to change notification settings - Fork 31
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
fix: remove refs issue #55
Conversation
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: eddycharly The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Looks like in this bug's case the schema for the field that's being resolve looks like: "strategy": {
"allOf": [
{
"$ref": "#/components/schemas/io.k8s.api.apps.v1.DeploymentStrategy"
}
],
"default": {},
"description": "The deployment strategy to use to replace existing pods with new ones.",
"x-kubernetes-patch-strategy": "retainKeys"
}, This bug can happen if there is a field-level override of the referred schema. I am curious if other cases like this exist. The proposed solution would lose the information that the field uses This part of the code is completely a hack to satisfy the requirements of structural schema which does not like new properties inside allOf (structural schema is required to run validators). Upstream we have a loose plan to add validation that does not require the structural schema and operates instead on kube-openapi for both CRs and native types. This goal is long away, so we have this hack. xref: kubernetes/kubernetes#106387 I'm thinking if we see a schema that meets the following conditions:
Then it should just be interpreted as a ref without any additional checks. We can be confident in this approach since k8s apiserver is the only source of We should create a copy of the referred schema, and set all non-empty properties of the field's override schema onto the referred schema. So in the case of
|
Thanks @alexzielenski for the detailed explanation. I will try to implement what you suggested today. |
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
@alexzielenski i'm not very familiar with this code, I tried to follow your explanations but tests are failing, would you mind giving a look please ? |
vCopy := removeRefs(defs, sch.AllOf[0]) | ||
vCopy.Default = sch.Default | ||
vCopy.Description = sch.Description | ||
if sch.Extensions != nil { |
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.
probably want to copy all nonzero properties and not just Default, Description, Extensions. Not sure if there is a clean go-ey way to do that
If you base on #60 I think some of the issues can go away. That would just leave the last comment from my last review to resolve |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@alexzielenski: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR fixes a
removeRefs
issue.It looks like we need to reset extensions before comparing with an empty schema.
Fixes #54