kubernetes-client
kubernetes-client copied to clipboard
[crd-gen] Support openAPIV3Schema fields: minimum, maximum, pattern, nullable
Is your enhancement related to a problem? Please describe
(duplicate of #2959)
At the moment there is no way to auto generate a crd (with crd-gen tool) that contains properties with validation fields like minimum, maximum, pattern, nullable.
CRD example:
...
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: tenants.example.com
spec:
group: example.com
names:
kind: Tenant
plural: tenants
singular: tenant
scope: Namespaced
versions:
- name: v1
schema:
openAPIV3Schema:
properties:
spec:
properties:
kafka:
type: object
properties:
port:
type: integer
minimum: 0
maximum: 65535
nullable: false
hostname:
type: string
pattern: '^([A-Za-z0-9-]{1,63}\.)+[[A-Za-z0-9-]{1,63}$'
nullable: false
nullable: false
...
Describe the solution you'd like
I'd like to use javax annotation (like @min @max @pattern
) on a java model fields.
private String protocol;
@Pattern(regexp = "\\^\\(\\[A-Za-z0-9-]\\{1,63}\\\\\\.\\)\\+\\[\\[A-Za-z0-9-]\\{1,63}\\$")
private String hostname;
@Min(0)
@Max(65535)
private Integer port;
Currently @NotNull annotation generate the filed "required" on crd, but for "nullable" validation maybe we need of a new specific annotation.
Describe alternatives you've considered
No response
Additional context
version: 5.12.2
Is the pattern in your model example correct? The ^
and parentheses should not be literals, for example. The only change from the yaml should be escaping the one \\.
@OneCricketeer Yes you are right but is not important the regex value now...The problem here is that crd-gen not have the featuare to read @Pattern @Max @Min
and to generate corresponding fields(pattern, maximum and minimum) into the generated crd yaml file.
I think that the logic to handle this annotations should be into AbstractJsonSchema as for the other already supported annotations.
@andreaTP could you have a look at this issue?
I'm about to go on vacation, but if no one picks it up earlier I might eventually take a look at this.
Relates to:
- https://github.com/fabric8io/kubernetes-client/issues/2611#issuecomment-745088459
- https://github.com/fabric8io/kubernetes-client/issues/2959 (duplicate)
I have to admit that I'm a little lost on the subtleties of required
and nullable
… if something is not marked as required
, shouldn't it be nullable
by default? Conversely, if something is marked required
, it cannot be nullable
so I'm not sure why we need to support both… especially because then there might be conflicts i.e. what is the generator supposed to do (apart from throwing an error, I guess) if a property is both marked as nullable
and required
?
Closed in #4348