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:
oneOf the subschemas to be fulfilled. Either
true in which case we require
uri be defined. Or,
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.