Strimzi v1 CRD API and 1.0.0 release

[scholzj]

This PR opens the proposal for how we should deal with the v1 CRD API, its introduction, removal of the older API versions, and finally the release of Strimzi 1.0.0. While there are some open points left, they can be done in a separate follow-up proposals. So please do not hesitate to review it 😉.

[fvaleri]

@scholzj thanks for this proposal.

I have a few comments.

[PaulRMellor]

Transition steps and required changes are outlined clearly.
Bump to 1.0.0 makes sense on the back of the transition to v1, but that would be subject to maintainer consensus
I left a few minor comments

[fvaleri]

LGTM, thanks.

[ppatierno]

I am confused now, because you commented:

But basically, if the CRD is too big, kubectl apply will nto work for it. So we make it smaller by leaving out the API descriptions while having both v1beta2 and v1 versions.

So AFAIU "without the description fields" while here I read "with the description fields".
Also, isn't it good having descriptions in the CRD? Isn't it something you can get via the kubectl describe instead of going to the doc?

[scholzj]

That is a typo, yes. It should be without.

[scholzj]

Also, isn't it good having descriptions in the CRD? Isn't it something you can get via the kubectl describe instead of going to the doc?

Well, it is not perfect. That is why I mention it in the proposal. But I believe it is still better to not have the descriptions than have to:

• Update all our docs to cover the whole kubectl create / kubectl replace process
• Handle all the questions from users who will still use kubectl apply and it would fail for them
• Handle all the questions from the users who did not even noticed kubectl apply failed for them

[ppatierno]

While removing descriptions helps now, it could just delay the problem later if the CRDs increase. Anyway I have not strong opinion on it. Curious to know what other @strimzi/maintainers think about it.

[scholzj]

So, it depends on what later do you really mean. Keep in mind that:

• The transition to v1 requires both versions in the CRD. Once we drop v1beta2 it will be small again
• The v1 drops all kinds of options around ZooKeeper, so it is smaller than the v1beta2
• We also need to think a bit more about the APIs we add. I think Deprecate and remove the type: oauth and type: keycloak APIs #175 is an example of where it grew up huge without much added value compared to having just some unstructured config map. So we should try to take these lessons and apply them, for example, here Proposal for supporting connections.max.reauth.ms configuration for SCRAM listeners #173

[katheris]

This all makes sense to me and I'm happy with the proposed changes. Only had a couple of nits and I wonder if it's worth stating anywhere that since the Access Operator CRDs are versioned separately (it's currently using the API version v1alpha1) the API version for that is remaining unchanged.

[katheris]

Suggested change

	Instead of updating all our docs and forcing users to use `kubectl creat` / `kubectl replace` instead of `kubectl apply`, we will generate the `Kafka` CRD without the `description` fields.
	Instead of updating all our docs and forcing users to use `kubectl create` / `kubectl replace` instead of `kubectl apply`, we will generate the `Kafka` CRD without the `description` fields.

Will this effect the generation of the docs? I personally use CRD yaml files and the description fields to check what a field is used for. Would it be possible to include the description field for the v1 API but not v1beta2?

[scholzj]

 Will this effect the generation of the docs?

No, the docs will not be affected.

Would it be possible to include the description field for the v1 API but not v1beta2?

Including the description for at least one version is unfortunately not possible. Both are needed to get the file under the size limit.

---

I added both to the proposal.

[scholzj]

I wonder if it's worth stating anywhere that since the Access Operator CRDs are versioned separately (it's currently using the API version v1alpha1) the API version for that is remaining unchanged.

I added an Out of Scope section saying that the Access OPerator is out of scope and not affected by this.

[im-konge]

Thanks for the proposal, just few comments.

[ppatierno]

LGTM.

[scholzj]

This has now 4 binding and 2 non-binding +1 votes. If there are no more comments, I will close it as approved on Thursday.

[scholzj]

Approved with 4 binding and 2 non-binding +1 votes