Support generating CRDs with logical constraints using [ "oneOf", "allOf", "anyOf", "not" ]

[matteriben]

Is your enhancement related to a problem? Please describe

I would like to be able to generate a CRD that includes logical constraints using [ "oneOf", "allOf", "anyOf", "not" ].

For example:

type: object
properties:
  spec:
    type: object
    properties
      command:
        type: string
      shell:
        type: string
    oneOf:
    - required: [“command”]
    - required: [“shell”]

Describe the solution you'd like

Express these constrains for the CRD generator using java annotations?

For example something like:

@OneOf(either = {
  @Alternative(constraints = {
    @Required(name = "command")
  }),
  @Alternative(constraints = {
    @Required(name = "shell")
  })
})
public class ExampleSpec {
  String command;
  String shell;
}

Describe alternatives you've considered

Perhaps these constraints could possibly be expressed through OOP?

For example something like:

public abstract class ExampleSpec {
}

public class ExampleSpecCommand extends ExampleSpec {
  String command;
}

public class ExampleSpecShell extends ExampleSpec {
  String shell;
}

Additional context

https://kubernetes.io/blog/2019/06/20/crd-structural-schema/

[andreaTP]

Stepping by to say that this is going to be a pretty massive amount of work, and support of the constructs is going to have nuances.

I have been involved in (part of) it with the Kiota project, and this compatibility matrix is part of the end result.

I encourage anyone that want to look into this to start with a detailed proposal of the mappings that should be supported.

[matteriben]

@andreaTP Thank you for your response!

---

Stepping by to say that this is going to be a pretty massive amount of work, and support of the constructs is going to have nuances.

I agree, just trying to describe a desired solution when creating this issue seemed non-trivial!

---

I have been involved in (part of) it with the Kiota project, and this compatibility matrix is part of the end result.

If I understand correctly kubernetes restricts the use of these logical constraints. As a result, I think only "peer properties" from the compatibility matrix (not "inline schemas" or "referenced schemas") are possible in CRD schemas.

According to this blog post: https://kubernetes.io/blog/2019/06/20/crd-structural-schema/

The core of a structural schema is an OpenAPI v3 schema made out of

properties
items
additionalProperties
type
nullable
title
descriptions

To sum up, an OpenAPI schema is structural if


1. it has the core as defined above out of properties, items, additionalProperties, type, nullable, title, description,
2. all types are defined,
3. the core is extended with value validation following the constraints:
    (i) inside of value validations no additionalProperties, type, nullable, title, description
    (ii) all fields mentioned in value validation are specified in the core.

---

I encourage anyone that want to look into this to start with a detailed proposal of the mappings that should be supported.

I don't have a detailed proposal, but I agree with you that this is the right place to start.

[baloo42]

Stepping by to say that this is going to be a pretty massive amount of work, and support of the constructs is going to have nuances.

I have the same opinion, this won't be an easy task and also needs some refactoring first. But as mentioned by @matteriben it's important to know that we don't have to implement it fully. We can focus on those parts which are supported by Kubernetes. The low level approach with Jackson in v2 might be helpful here.

It might be also good to collect and look first into existing implementations.

victools/jsonschema-generator supports anyOf, allOf and oneOf but not not.

Does someone know other Java jsonschema generators based on Jackson?

I did last year an experiment and implemented a CRD-Generator based on victools/jsonschema-generator:

https://github.com/baloo42/crd-generator-victools

An example using @JsonSubTypes to produce anyOf can be found here:
Java Sources
CRD Output

We should also talk about which additional annotations would be required and which from Jackson itself can be reused.

@matteriben Do you already have other additional or existing annotations in mind?

[matteriben]

@matteriben Do you already have other additional or existing annotations in mind?

@baloo42 I'm sorry, but I do not.