This advice is valid for sure if you're working with a Kubernetes CRD with version like this:
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
It might be valid for other versions too.
If you want to create a structural CRD, and you want to require something not be there when some other value is set one way or another, here's an example.
prometheus:
type: object
oneOf:
- required:
- enabled
- uri
properties:
enabled:
enum:
- true
- properties:
enabled:
enum:
- false
allOf:
- not:
required:
- uri
properties:
enabled:
description: Whether or not to enable the Presto-Prometheus connector.
type: boolean
uri:
description: URI for Prometheus.
type: string
format: uri
chunkSizeDuration:
description: Default size of each Prometheus query chunk.
So that means:
We require oneOf the subschemas to be fulfilled. Either enabled is true in which case we require uri be defined. Or, enabled is false in which case, uri is not required. The extra allOf in there, in this case, is simply a way to allow for the not in that 2nd subschema. And just highlight what is meant by subschemas. oneOf starts a list of them. So the first is:
- required:
- enabled
- uri
properties:
enabled:
enum:
- true
and the second is:
- properties:
enabled:
enum:
- false
allOf:
- not:
required:
- uri
And to be structural you must list all the properties again, and you can include any items you're not setting requirements on. Which is the rest of the yaml above.
Happy computing.
Top comments (0)