like #6 but status is also optional.
it says so in the description:
https://github.com/garethr/openshift-json-schema/blob/0248a51928a076297dbc0474b5286b271ec2d679/v4.1.0/_definitions.json#L5506-L5521
"com.github.openshift.api.route.v1.RouteSpec": {
"description": "RouteSpec describes the hostname or path the route exposes, .....",
"required": [
"host",
"to"
],
"properties": {
"alternateBackends": {
"description": "alternateBackends allows up to 3 additional backends to be assigned to the route. Only the Service kind is allowed, and it will be defaulted to Service. Use the weight field in RouteTargetReference object to specify relative preference.",
"type": "array",
"items": {
"$ref": "#/definitions/com.github.openshift.api.route.v1.RouteTargetReference"
}
},
"host": {
"description": "host is an alias/DNS that points to the service. Optional. ......"
//...similarly, status cannot be required when sending from the client --- in fact it should probably be null, because it is reserved from communication from the server to the client.
by listing both as required, it is not possible to construct both a schematically and semantically valid object. (they are a bit mutually exclusive in my understanding)
like #6 but status is also optional.
it says so in the description:
https://github.com/garethr/openshift-json-schema/blob/0248a51928a076297dbc0474b5286b271ec2d679/v4.1.0/_definitions.json#L5506-L5521
similarly, status cannot be required when sending from the client --- in fact it should probably be null, because it is reserved from communication from the server to the client.
by listing both as required, it is not possible to construct both a schematically and semantically valid object. (they are a bit mutually exclusive in my understanding)