Default value not allowed for in x-kubernetes-list-map-keys

[tamalsaha]

I filed the issue in k/k: kubernetes/kubernetes#91395

I am cross posting here because I don't know if this is an issue in the upstream CRD validation or the YAML generated by controller-tools.

[tamalsaha]

/kind bug

[liggitt]

In a v1beta1 CRD, a property specified as a list-map item key must be a required property.

In a v1 CRD it can be a required property or be given a default value

[tamalsaha]

The example CronJob yaml in controller-tools project also does not work in 1.18

https://github.com/kubernetes-sigs/controller-tools/blob/v0.3.0/pkg/crd/testdata/testdata.kubebuilder.io_cronjobs.yaml

$ kubectl version --short
Client Version: v1.18.3
Server Version: v1.18.2

$ kubectl create -f https://github.com/kubernetes-sigs/controller-tools/raw/v0.3.0/pkg/crd/testdata/testdata.kubebuilder.io_cronjobs.yaml
The CustomResourceDefinition "cronjobs.testdata.kubebuilder.io" is invalid: 
* spec.validation.openAPIV3Schema.properties[spec].properties[jobTemplate].properties[spec].properties[template].properties[spec].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property
* spec.validation.openAPIV3Schema.properties[spec].properties[jobTemplate].properties[spec].properties[template].properties[spec].properties[containers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property
* spec.validation.openAPIV3Schema.properties[spec].properties[embeddedResource].properties: Required value: must not be empty if x-kubernetes-embedded-resource is true without x-kubernetes-preserve-unknown-fields

@liggitt , how does CRD authors add default value for core/v1 types used in their CRD like done here?

https://github.com/kubernetes-sigs/controller-tools/blob/master/pkg/crd/testdata/cronjob_types.go#L77-L78

[tamalsaha]

@liggitt ,
Do you think we can add a pr like
kmodules/api@c8bc107

to solve this issue?

[kensipe]

@tamalsaha your suggested fix will help the kubebuilder community (and may be worth it)... but we should look to have a solution in controller-tools for all projects that use controller-runtime (in lieu of a core fix that defines how defaults are expressed)

[kwiesmueller]

/cc @jennybuckley

[kwiesmueller]

/cc @jpbetz

[tamalsaha]

The proper solution is to write a KEP and update the k/api types with the new annotations. See here: kubernetes/kubernetes#91395

My personal hack has been just use my forked api repo with kubebuilder:default annotation. It unblocked me for now. kmodules/api@c8bc107

[kensipe]

@tamalsaha The solution discussed in the WG API Expression meeting today (which is a WG for api-machinery) is that @jennybuckley is working on a solution (I think for controller-gen). I specifically asked about the need for a KEP with answers being redirected to Jenny is working on it. Here is the meeting agenda: https://docs.google.com/document/d/1CSpNaicbEqKJoW306qaQEBIkwC1mGIcKl3yiB_C0HZk/edit
unfortunately there were no minutes / notes taken for the discussion.

the /cc: ^^ were to ensure that the solution being worked on covers these cases.

[estroz]

#440

[munnerz]

In order to reduce the confusion that this causes, after a discussion with @pwittrock, we were thinking of adding a couple of extra code areas into controller-gen to help here whilst we wait for the eventual upstream solution:

1. adding in a 'validation' step to controller-gen to actually inform the user that the CRD manifest generated/the input API types are not going to be valid in Kubernetes 1.18+
2. adding in explicit mappings from field names->default values for some of these commonly affected types in the core API

This will at least allow users to move forward today with installing their resources into Kubernetes 1.18 clusters without having to fork kubernetes/api

[dvaldivia]

@munnerz do you think there's a work around meanwhile?

[sudhakso]

Move to controller-gen@0.2.0 has at least got me past the issue. I am trying these CRDs and controllers on k8s@v1.18

[knrt10]

Current hack, moving to controller-gen@0.2.0 fixed the issue.