What problem are you facing?

Some function packages include CRDs in their xpkg artifact. If a function package includes a CRD, the package manager will install it. This was an unintentional implementation oversight. Functions were never supposed to use actual CRs, and the package manager was never supposed to install their CRDs.

Functions take an input, which looks like a Kubernetes CR written inline of a Composition. In practice this is an x-kubernetes-embedded-resource field, i.e. a schemaless resource, within the Composition. Most Go functions that want to take an input define an input Go type the same way they'd define a CRD - using controller-tools. They then deserialize the input from the RunFunctionRequest into the Go type. It's this use of controller-tools that lead to accidentally creating a CRD. Functions written in languages other than Go (e.g. Python) are very unlikely to include a CRD, since they never use controller-tools.

At least one function that I'm aware of actually uses its CR - i.e. the user is expected to create one, which the function then loads. This is https://www.hyrumslaw.com in action.

There are two known issues with installing these CRDs:

1. design: Propose a new approach to controlled rollout of composition functions #6935 proposes we support running multiple different versions of one function simultaneously within a single control plane.
2. The RBAC manager doesn't handle them (like it does provider CRDs), so nothing has permission to actually use them. ClusterRoles management for Functions #6841 would address this.

I think doing 1 is important, and if we keep installing function CRDs it'll place awkward and unintuitive constraints on functions. They'd never be able to change their CRD - even typically backward compatible changes wouldn't be possible. We'd need guarantee that all running versions of the function will always understand any extant CR.

How could Crossplane help solve your problem?

I think Crossplane should stop installing function CRDs. We could perhaps do this as part of the feature flag that enables #6935.

The only viable alternative I can think of is to go with what I mentioned above - functions can install CRDs but they can never change them, at all. If you're running four different versions of the same function, Crossplane installs the CRD for whatever version you installed last.

(I reused an old issue for this proposal. Original issue below.)

What happened?

A Function package may optionally define a schema for its input. We use a CRD to capture the input schema, since it's a KRM-like object. This is mostly useful for documentation purposes, since many tools can extract and parse the schema from a CRD. e.g.:

https://marketplace.upbound.io/functions/crossplane-contrib/function-patch-and-transform/v0.2.1/resources/pt.fn.crossplane.io/Resources/v1beta1

Nothing in a control plane actually uses this CRD, so there's not currently any reason to install it. In fact I suspect our documentation says it doesn't get installed. It turns out it does.

How can we reproduce it?

Install a Function that has an input CRD and kubectl get crds.

What environment did it happen in?

Crossplane version: