Kubernetes v1.18 Support (OpenShift 4.5)

[otaviof]

Deploying the operator resources, in a Kubernetes v1.18.3 cluster, returns the following error:

$ bash -x ./hack/crd.sh install
# ...
+ kubectl apply -f deploy/crds/build.dev_buildstrategies_crd.yaml
The CustomResourceDefinition "buildstrategies.build.dev" is invalid: spec.validation.openAPIV3Schema.properties[spec].properties[buildSteps].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
+ die 'Unable to install '\''deploy/crds/build.dev_buildstrategies_crd.yaml'\'''
+ echo '[ERROR] Unable to install '\''deploy/crds/build.dev_buildstrategies_crd.yaml'\'''
[ERROR] Unable to install 'deploy/crds/build.dev_buildstrategies_crd.yaml'
+ exit 1

The issue comes from deploy/crds/build.dev_buildstrategies_crd.yaml:578, specifically at x-kubernetes-list-map-keys property, also used on ClusterBuildStrategy CRD. This error means the OpenAPI validation generated for the build-v2 operator is not compatible with the newer Kubernetes version (1.18).

Checking upstream operator-sdk, there's a issue explaining more details. Currently we employ operator-sdk version 0.17.0.

[qu1queee]

@otaviof if I recalled correctly, we are blocked by operator-sdk not support this k8s version.

[otaviof]

@otaviof if I recalled correctly, we are blocked by operator-sdk not support this k8s version.

Alternatively, we might want to edit those files manually, and keep watchful until the issue is fixed.

[sbose78]

Could we start using operator-sdk 0.18.x ?

[otaviof]

Could we start using operator-sdk 0.18.x ?

I think that's not possible, as per operator-sdk #3235 still open.

[sbose78]

Ah so even with https://github.com/operator-framework/operator-sdk/releases/tag/v0.18.1 things wouldn't work?
🤕

we might want to edit those files manually, and keep watchful until the issue is fixed.

We could do that, I think, Otavio. Thoughts, @qu1queee @zhangtbj ?

[zhangtbj]

If we edit the crd yamls manually, those yaml files will be overridden if we have any CRD update and run operator-sdk generate crds later, so it is better to avoid it :)

One more question, if we move to v1.18, is it still compatible with kube 1.17?
For example the property x-kubernetes-list-map-keys

[otaviof]

If we edit the crd yamls manually, those yaml files will be overridden if we have any CRD update and run operator-sdk generate crds later, so it is better to avoid it :)

Checking the issue twice, we are not even able to solve it manually. To add more details, the issue comes directly from core-v1/Container usage, specifically at ports attribute. The error message reads:

this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property

Since it comes from dependencies that are not under control of this project, we also can't change it directly anyways. :-(

One more question, if we move to v1.18, is it still compatible with kube 1.17?
For example the property x-kubernetes-list-map-keys

Yes, it would be compatible with older Kubernetes version. The changes in v1.18, makes only the validaton more strict.

[qu1queee]

@otaviof thanks for the details. Lets then monitor for now, I´m more than happy on doing the bump once is possible.

[sbose78]

Openshift 4.5 is out, we should aim for a resolution on this one.

[zhangtbj]

Hi @otaviof ,

Is there any update for this issue?

Thanks!

[adambkaplan]

/close

We got k8s 1.18 support with #462

[openshift-ci-robot]

@adambkaplan: Closing this issue.

In response to this:

/close

We got k8s 1.18 support with #492

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.