Skip to content
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

Workaround for int-or-string format issues #2

Closed
wants to merge 1 commit into from
Closed

Conversation

garethr
Copy link
Collaborator

@garethr garethr commented Jul 1, 2017

Kubernetes happily expects integers to be passed to fields of type
string, if they have the format int-or-string. This means the schema is
valid (because the rules around format are hazy) but actually validating
a document against a schema will fail - correctly in my view.

The proper fix for this likely involves some discussions with api
machinery and even some spec wrangling. In the meantime I'm going to
work around it here.

This first pass is pretty blunt. It has the potential to pass some
invalid documents with a warning. With a more specific jsonpath query,
and some parsing based on the Field() it's probably possible to make
this more accurate.

Kubernetes happily expects integers to be passed to fields of type
string, if they have the format int-or-string. This means the schema is
valid (because the rules around format are hazy) but actually validating
a document against a schema will fail - correctly in my view.

The proper fix for this likely involves some discussions with api
machinery and even some spec wrangling. In the meantime I'm going to
work around it here.

This first pass is pretty blunt. It has the potential to pass some
invalid documents with a warning. With a more specific jsonpath query,
and some parsing based on the Field() it's probably possible to make
this more accurate.
@garethr
Copy link
Collaborator Author

garethr commented Jul 2, 2017

A conversation about this on SIG API Machinery (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/QcZG6UIrEgk) has me thinking about a better fix, specifically processing the schemas to swap this for oneOf. I'll try that out as that would be much much nicer.

@garethr
Copy link
Collaborator Author

garethr commented Jul 3, 2017

Closing in favour of #3.

I've updated the schemas to swap in oneOf which appears to work much nicer.

@garethr garethr closed this Jul 3, 2017
@garethr garethr deleted the int-or-string branch July 8, 2017 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant