Update apiserver-builder from 1.9, or switch to CRDs?

[dlipovetsky]

Some core components depend on apiserver-builder v1.9-alpha.3, which depends on Kubernetes 1.9.x. Therefore components are locked to the Kubernetes 1.9.x.

Updating apiserver-builder to a newer release does not seem trivial. The project is not actively maintained. Kubebuilder--a similar project that targets CRDs--is actively maintained. CRDs do not have feature parity with API extension servers, but are closer than a few releases ago, when Cluster API chose them over CRDs. In light of the above, the time seems right to revisit the choice.

Core components that are generated by (and import) apiserver-builder:

• Generated API code /pkg/apis
• Generated OpenAPI spec /pkg/openapi
• Cluster API controllers /pkg/controller
• API server /cmd/apiserver
• Controller manager /cmd/controller-manager

Why does cluster API need an updated apiserver-builder?

The cluster API controllers may have issues running on a 1.11 or newer cluster. The Kubernetes control plane is guaranteed to be compatible with the previous minor version, so the cluster API controllers should have no issues running on a 1.10 cluster.

[dlipovetsky]

The apiserver-builder project appears to not be active; the latest commit is in the v1.9-alpha.3 release from May 6. The kubebuilder project may be a good option in the future, but today does not provide functionality we get from apiserver-builder[0].

[0] Based on @medinatiger's comments at the WG 6/27/2018 meeting.

[krisnova]

Wondering if this is alluding to the discussion of switching back to CRDs?

[dlipovetsky]

@kris-nova Yes. I should have been more explicit: kubebuilder is for CRDs only, so we could use it only if we switched back to CRDs.

For reference: CRDs have gained parity with Aggregated APIs since the time the of the decision to use an Aggregated API.

[davidewatson]

Though I do suspect cluster-api should move to CRDs for the maintenance reasons discussed here on "Wed 14 February 2018".

[mvladev]

One of the key of the missing things CRDs is version conversion - especially when you need custom conversion (field X is spitted into fields Y and Z for example). The good thing is that there is a design document for this change - http://bit.ly/k8s-crd-conversion
The other thing that is missing is subresources. We at the moment don't use it, but we might in the future.
I'm for CRDs change.

[dims]

+1 to move to CRDs

[ingvagabund]

@enxebre FYI

[roberthbailey]

We discussed this issue during the working group meeting today and the consensus is that folks think we should move back to CRDs. @detiber has started doing some prototype work using kubebuilder (see https://github.com/detiber/cluster-api-crd) but we could use some help moving this issue forward.

[randomvariable]

What's needed to move this forward, and do we want it done within the 1.12 timeframe?

[detiber]

@randomvariable So far in https://github.com/detiber/cluster-api-crd I have the basic API structs migrated over, but work still needs to be done to finish up the generated controllers, adding the validating webhooks to ensure validation parity, and adding the mutating webhooks for setting default values.

It'll probably be next week sometime before I'll be able to continue any work on it. I'm more than happy to add additional collaborators to the repo for anyone that wants to help move the conversion forward.

[detiber]

As an update, the current work to enable this has moved into #494

[scruplelesswizard]

I don't think this issue meets the requirements for the help wanted label.

Please feel free to re-add if you disagree.

/remove-help

[davidewatson]

@roberthbailey, @pwittrock: Is there anything left to do for this issue?

[roberthbailey]

Nope; fixed by #494.