Add marker to skip/ignore specific fields on CRD generation

[luisdavim]

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.

[sbueringer]

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]

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]

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[luisdavim]

/remove-lifecycle stal

[luisdavim]

/remove-lifecycle stale

[JoelSpeed]

Where you are re-using the structs, you mention it's not possible to avoid? Can you provide an example?

Where I have seen structs re-used before, one common technique is for folks to use CEL to prevent fields within the re-used struct being set at certain points in the API. E.g. folks using a reference type that has a namespace in it, but for a non-namespace object

// +kubebuilder:validation:XValidation:rule="!has(self.namespace)",message="setting myObjectRef.namespace is not permitted"
MyObjectRef ObjectRefType `json:"myObjectRef"`

[luisdavim]

My problem is not so much as users being able to set the fields, it's more about the fields not being added to the CRD spec in the first place.
In my case the tool has 2 modes, where it can run as a CLI or as a server, in the CLI mode it reads the configuration from a file and in server mode it can still read the file but it can also be configured through custom resources. This was a while back and I don't remember the details, I'll try to dig them up and see what I can share.

Thanks

[JoelSpeed]

If the field is in the spec, but cannot be set, what issue does that cause? Is it more from and kubectl describe or generated API docs perspective we are trying to avoid confusion?

[luisdavim]

The issue is that it is confusing to see fields in the documentation that are ignored. When we auto generate docs and if a user uses explain to get details about the API.

[JoelSpeed]

To make something like this usable, I think we would need to have a way to path the skip behaviour, eg, +skip:field="self.foo". That way it could be used where the field references a struct to ignore fields within the struct, that is plausibly outside of our own control. If you wanted to ignore a specific field within a struct always, you already can that at with the json:"-" tag.

Something like this would also help to solve issues like #1168 (comment) where creationTimestamp is being generated, but isn't actually desirable.

[JoelSpeed]

We may want to look into the k8s:subfield style that is being introduced into core API validation

[luisdavim]

I was thinking something more like the // +optional but in this case it would be // +skip or // +ignore and just not add it to the CRD spec when generating the manifest.