garethr / openshift-json-schema Goto Github PK

Currently imagePullPolicy is just:

"imagePullPolicy": {
          "type": "string", 
          "description": "Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/images#updating-images"
 }

But should have enum for always, never, and IfNotPresent

Even though, in OC 3.11, the ingress resource is housed under v1beta1, if I pass an ingress under networking api, kubeval says it's valid.

https://docs.openshift.com/container-platform/3.11/rest_api/apis-extensions/v1beta1.Ingress.html

RedHat update (fixes) the OpenAPI spec for openshift 3.11

Fields like route.spec are not required anymore..

(openshift/origin@9ecc5b5)

@garethr I remember a discussion in some other repository about this. My colleague @hrishin is working on it for maven packages. What would be a good place to host the changes? Should we open PRs against this repo?

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)