Operator-sdk: Generated CRD subresources and schema not honored

[joelanford]

Bug Report

What did you do?

1. Build operator-sdk from master
2. Create new go project
3. Create new api and controller
4. Update _types.go file to include a new field in the status
5. Update controller to set the new status field on the CR and make a call to update the status (returning any error)
6. Run operator-sdk generate k8s && operator-sdk generate openapi
7. Apply CRD and CR
8. operator-sdk up local

What did you expect to see?

1. Everything running normally and the status field updated on the CR
2. kubectl get crd apps.example.com -o yaml to include the subresource setting somewhere

What did you see instead? Under which circumstances?

1. Failures trying to update the status, with an error indicating that the subresource does not exist
2. The in-cluster CRD does not include any mention of a subresources.status setting or the schema section that ARE present in disk, under the v1 version.

Environment

• operator-sdk version:

operator-sdk version: "v0.10.0-48-g5f663690", commit: "5f663690a3bb97bf7b9e9b8a15a2f8d6bc481808", go version: "go1.13 darwin/amd64"

• go version:

go version go1.12.7 darwin/amd64

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:49Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:16Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind: minikube (local)

• Are you writing your operator in ansible, helm, or go? go

Possible Solution

• Make subresources a top-level field
• Move schema to the top-level validation field.

Additional context

• I repeated similar steps using kubebuilder and noticed that it produces a CRD with a top-level subresources section.
• I repeated the same steps using a Kubernetes 1.15 cluster and got CRD validation errors trying to create the CRD:
  The CustomResourceDefinition "apps.example.org" is invalid: <ul> <li>spec.versions: Invalid value: []apiextensions.CustomResourceDefinitionVersion{apiextensions.CustomResourceDefinitionVersion{Name:"v1", <a href="Served:true">Served:true</a>, <a href="Storage:true">Storage:true</a>, Schema:(<em>apiextensions.CustomResourceValidation)(0xc00ad95438), Subresources:(</em>apiextensions.CustomResourceSubresources)(0xc004f98ed0), AdditionalPrinterColumns:[]apiextensions.CustomResourceColumnDefinition(nil)}}: per-version schemas may not all be set to identical values (top-level validation should be used instead)</li> <li>spec.versions: Invalid value: []apiextensions.CustomResourceDefinitionVersion{apiextensions.CustomResourceDefinitionVersion{Name:"v1", <a href="Served:true">Served:true</a>, <a href="Storage:true">Storage:true</a>, Schema:(<em>apiextensions.CustomResourceValidation)(0xc00ad95438), Subresources:(</em>apiextensions.CustomResourceSubresources)(0xc004f98ed0), AdditionalPrinterColumns:[]apiextensions.CustomResourceColumnDefinition(nil)}}: per-version subresources may not all be set to identical values (top-level subresources should be used instead)<br />

/cc @estroz @hasbro17

[flickerfly]

Is testing on this with an Ansible operator needed?

[joelanford]

@flickerfly I don't believe so. My hunch is that there's an issue with controller-tools (or our usage of it), and controller-tools is scoped to Go-related generation.

I don't think this impacts the Ansible operator.

[joelanford]

This should be solved in controller-tools by https://github.com/kubernetes-sigs/controller-tools/pull/322

We'll have to re-vendor controller-tools after this is merged.