Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add marker to skip/ignore specific fields on CRD generation #1062

Open
luisdavim opened this issue Sep 18, 2024 · 3 comments
Open

Add marker to skip/ignore specific fields on CRD generation #1062

luisdavim opened this issue Sep 18, 2024 · 3 comments

Comments

@luisdavim
Copy link

luisdavim commented Sep 18, 2024

Similar request to #521 and https://groups.google.com/g/kubebuilder/c/N2A8FYNuWLA (both ended up unanswered 😞 )

In some cases we might re-use structs for CRDs and some other configuration and want to prevent certain fields form being added to the CRDs, something like a // +skip or // +ignore would be nice.

@luisdavim luisdavim changed the title Add marker to skip/ignore specific fields Add marker to skip/ignore specific fields on CRD generation Sep 18, 2024
@sbueringer
Copy link
Member

In general I'm not sure if it's a good idea to reuse structs when there's not a 100% fit. E.g. see the explanation here: https://github.com/kubernetes/kubernetes/blob/v1.32.0/staging/src/k8s.io/api/core/v1/types.go#L6886-L6896

@JoelSpeed What do you think about supporting this?

@JoelSpeed
Copy link
Contributor

In some cases we might re-use structs for CRDs and some other configuration

Can you provide a more detailed explanation of a use case for this?

Generally, from an API reviewers perspective, you want the types to be clean and focused directly on the API. Think about clients (people building tools against your API) using your types, if they pull in the Go type, how would they understand that the extra fields you have +skip on, are actually not valid fields within the API? Their IDE isn't likely to point that out to them is it?

@luisdavim
Copy link
Author

In our case we have a packaging system and a congregation file to allow building packages parts of that configuration can be used with a controller to deploy the packages, not all the fields in the struct are relevant to the controller parts. We do use separate structs and composition to avoid this as much as possible but it's not always possible. The extra fields don't cause issues as they are ignored by the controller but it can be confusing to the user seeing them when checking the API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants