crd-generator maintenance

[robzienert]

I asked this on gitter, but that community looks pretty inactive, so I'll repeat here:

I'm relatively new to the community, but am looking to generate CRD files from the annotation Java classes. By the looks of it, the crd-generator module has a lot of work to be done on it and I'm curious if it needs a new or another maintainer. Without looking too closely, I see that there are some major gaps that would prevent some adoption:

1. CRD version support is hard-coded, only allowing v1 and v1beta1. This needs to be updated to support alpha, as well as v1+, etc. From what I can tell, the code that supports the existing two use cases is predominantly copy/paste, so this could be cleaned up.
2. The apiVersion for the generated CRD is using v1beta1, which is deprecated and unavailable in v1.22+. This would also need to be updated.

I'd be interested to hear if this is a component of the project that (a) has any existing maintainer, and (b) is the community open to me taking on improvements to this module, specifically addressing the two points above? I'm eager to get this part of the project to a place that would be considered stable.

[andreaTP]

Hi @robzienert !
Thanks for your interest in the CRD generator, it is in preview state, so, feel free to contribute any improvement you need.

CRD version support is hard-coded, only allowing v1 and v1beta1

this is not correct the hard-coded versions are referring to the CRD apiVersion and it's not relevant for end user CRD version.

The apiVersion for the generated CRD is using v1beta1

the current generator generates both the v1 and v1beta1 apiVersions of the CRD.

(a) has any existing maintainer

The principal maintainer at this point in time is @metacosm I believe (can you @metacosm confirm?)

(b) is the community open to me taking on improvements to this module

I'm personally eager to see improvements there, the process, in my opinion should be:

• open an issue in this repository (possibly with a reproducer)
• check with maintainers that the issue is valid
• file a PR fixing it with proper testing etc.

[metacosm]

(a) has any existing maintainer

The principal maintainer at this point in time is @metacosm I believe (can you @metacosm confirm?)

I'm the person who took care of it up to this point, yes but contributions are very welcome, as you know, @andreaTP 😄

(b) is the community open to me taking on improvements to this module

I'm personally eager to see improvements there, the process, in my opinion should be:

* open an issue in this repository (possibly with a reproducer)

* check with maintainers that the issue is valid

* file a PR fixing it with proper testing etc.

👍🏼

[robzienert]

Oh no, I had a complete brain lapse while looking at the codebase. 🤣 Completely disregard the core problem statement of my original post. Thanks for the information re: contributing, however; I will certainly look to contribute as things crop up.

[metacosm]

1. CRD version support is hard-coded, only allowing `v1` and `v1beta1`. This needs to be updated to support `alpha`, as well as `v1+`, etc. From what I can tell, the code that supports the existing two use cases is predominantly copy/paste, so this could be cleaned up.

There currently are no other CRD versions. I'm not following the Kubernetes work closely but I'm not aware of any current work to change the current CRD spec so I don't really see this point as an issue.

The code is predominantly copy/paste indeed but if you pay attention to the details (that's always where the subtleties lie), you'll notice that they don't use the same version of the classes. Removing the code duplication would actually require quite a bit of work for not much benefit at this stage. Feel free to improve on this and submit a PR.