How to AND NOT something in a CRD

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.