Support more complex validations (oneOf/anyOf/allOf/etc)

[matthchr]

According to the structural schema, CRD schemas such as the one below (from the linked article) are allowed:

type: object
properties:
  spec:
    type: object
    properties
      command:
        type: string
        minLength: 1                          # value validation
      shell:
        type: string
        minLength: 1                          # value validation
      machines:
        type: array
        items:
          type: string
          pattern: “^[a-z0-9]+(-[a-z0-9]+)*$” # value validation
    oneOf:                                    # value validation
    - required: [“command”]                   # value validation
    - required: [“shell”]                     # value validation

As far as I can tell, it is not possible to generate a schema of this shape using controller-gen today. Specifically, the oneOf validation at the bottom cannot be represented using Kubebuilders validation annotations, as there is no way to specify oneOf (or anyOf/allOf/etc) via annotations that I can tell.

Is there a plan or vision for having controller-gen support more complex validation scenarios (or does it already and I've just missed how?)

[matthchr]

There is obviously a good amount of complexity in even supporting this scenario, as in order to generate a CRD with the above shape, there needs to be some way to create various validation "groups" and join them with an operator... maybe something like this...?

type Demo struct {
  // +kubebuilder:validation:MinLength=1
  // +kubebuilder:validation:OneOf[0]:Required
  command string
  // +kubebuilder:validation:MinLength=1
  // +kubebuilder:validation:OneOf[1]:Required
  shell string
  // +kubebuilder:validation:Pattern="^[a-z0-9]+(-[a-z0-9]+)*$"
  machines []string
}

I'm wondering if there's thought/energy in this space - I looked around and didn't really see many issues related to this topic (although there was #298 which is somewhat related).

[DirectXMan12]

I think #298 is the bulk of the existing discussion.

Largely, the background here is that we wanted to make it really hard/impossible to produce non-structural schemas (considering they're "invalid" in the soft sense -- you can't use new features with non-structural schemas).

I think, at the very least, we can extend/augment the union markers to generate validation, so that the patterns captured by x-kubernetes-union and such get converted to equivalent validation. It's a little stricter than general oneOf, but it's also in line with the general patterns of kubernetes.

To clarify from your usecase a bit further, what's the desired intent of the validation? Specifically, are you saying that:

• you must specify either command or shell, or both (not a thing discussed in kubernetes up to this point, I think)?
• you must specify either command or shell, but not both (an "embedded union (no tag)", in kubernetes terms, I believe)?

[matthchr]

The above was just an example honestly, speaking about a general problem which I think will solve my specific problem. It's possible I generalized a bit too soon though as you're right the case above is really a union case (and there are specific recommendations from Kubernetes on how to deal with those based on this enhancement proposal for unions)

My actual specific use case is: I want to create a CRD where there are two distinct sets of required parameters. For example something like this dummy CRD for a SQL database in a cloud:

type: object
properties:
  spec:
    type: object
    properties
      cloudName:
        type: string
        minLength: 1
      tier:
        type: string
        minLength: 1
      otherProperty1:
        type: string
      ... more properties, elided for brevity ...
    anyOf:
    - required: [“cloudName”]
    - required: [“cloudName, "tier", "otherProperty1", (and so on)]

I'm trying to convey that there are 2 (or 3 or whatever) minimum property sets for this resource. Structurally the object is the same regardless though (so it adheres to the structural schema requirements).

Ideally I could encode these requirements into the CRD itself, so that users land into one of the two supported "flavors".

Drawing parallels to code I want two different constructors/factory methods for this CRD type.

I know there are probably other solutions to accomplishing this goal (like putting the delta between each set of required properties into their own struct and marking them all required but the top level struct optional on the spec), but that forces me to increase the complexity of the resource by adding nesting, and especially for the common case I'm thinking of (one set is always just cloudName, the other set is cloudName + a bunch of properties) it would force most of the properties down a level since the delta between each set of required properties is large. Alternatively I could go full union-style and actually make two shapes but again that ends up complicating the structure in a way that isn't technically required by the YAML.

[christarazi]

This would also be helpful over at the Cilium project as well. Our use-case is even simpler:

type CiliumClusterwideNetworkPolicy struct {
        ...

	// Spec is the desired Cilium specific rule specification.
	Spec *api.Rule `json:"spec,omitempty"`

	// Status is the status of the Cilium policy rule.
	Status CiliumNetworkPolicyStatus `json:"status"`
}

type Rule struct {
	// EndpointSelector selects all endpoints which should be subject to
	// this rule. EndpointSelector and NodeSelector cannot be both empty and
	// are mutually exclusive.
	EndpointSelector EndpointSelector `json:"endpointSelector,omitempty"`

	// NodeSelector selects all nodes which should be subject to this rule.
	// EndpointSelector and NodeSelector cannot be both empty and are mutually
	// exclusive. Can only be used in CiliumClusterwideNetworkPolicies.
	NodeSelector EndpointSelector `json:"nodeSelector,omitempty"`
        ...
}

Essentially, we'd like to say that only one of endpoint selector or node selector must be provided, but not both.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[christarazi]

/remove-lifecycle stale

[s3rj1k]

Any news about this?
Would be super helpful to get this feature.

[antonlisovenko]

I'd say the one of required is a quite common use case...

oneOf:
            - required: [x]
            - required: [y]
            - required: [z]

Would be great to get controller-gen support for this!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale