Similar issue was reported here but this might be a better home for it, not sure.
In this code the tool conflates an optional field (i.e. a field that does not have to be specified) with a field that allows null values. But this is not correct and these are distinct things in some cases (e.g. Kubernetes schemas)
As a real world example, if you have a Kubernetes Deployment and set a secret volume like this (with secretName having the null value)...
...
spec:
volumes:
- name: somevol
secret:
secretName:
...
The schema produced from openapi2jsonschema using kubeval will happily consider this config valid. But if you try to apply the config using kubectl or kustomize, it complains that secretName cannot take a null value. And indeed if you look at the upstream schema, nowhere does it specify that the field is nullable.
Similar issue was reported here but this might be a better home for it, not sure.
In this code the tool conflates an optional field (i.e. a field that does not have to be specified) with a field that allows
nullvalues. But this is not correct and these are distinct things in some cases (e.g. Kubernetes schemas)As a real world example, if you have a Kubernetes
Deploymentand set a secret volume like this (withsecretNamehaving thenullvalue)...The schema produced from
openapi2jsonschemausingkubevalwill happily consider this config valid. But if you try to apply the config usingkubectlorkustomize, it complains thatsecretNamecannot take a null value. And indeed if you look at the upstream schema, nowhere does it specify that the field is nullable.