New repo: crossplane-contrib/provider-environment-configs

[phisco]

Name of new extension

provider-environment-configs (repo: crossplane-contrib/provider-environment-configs)

Purpose and intended scope of the extension

Crossplane v2 made composite resources (XRs) namespaceable (Compositions themselves remain cluster-scoped). A namespaced XR can't compose cluster-scoped resources, and EnvironmentConfig (apiextensions.crossplane.io/v1beta1) is cluster-scoped — so there is no way for a namespaced composite to create one, which breaks patterns like sharing a value (e.g. an id from one managed resource's status.atProvider) by having one composite produce an EnvironmentConfig that another consumes. See crossplane-contrib/function-environment-configs#105.

A function can't solve this on its own: the package manager does not install CRDs bundled in function packages — the xpkg spec allows CRDs there only to deliver input-type schema, and the function-revision controller filters them out. A provider is the only package type whose CRDs the manager installs, so a small provider is the natural home for a namespaced equivalent.

Alternatives considered and rejected: adding a namespaced EnvironmentConfig to core itself — e.g. under apiextensions.m.crossplane.io, mirroring the .m. namespaced-group convention providers adopted in v2 — would be the most native option, but it carries a longer core release timeline and cuts against a long-standing inclination in the project to move EnvironmentConfig out of core rather than expand it there. The remaining alternatives were all raised in #105: creating the cluster-scoped EnvironmentConfig indirectly via a provider-kubernetes Object (painful, cluster-scoped, and against the namespaced direction of v2); or exposing values in the composite's status and reading them via function-extra-resources (leaks confusing internal details into the end-user's composite status). Letting Function/Configuration packages install CRDs would be a cleaner long-term fix but is itself a core change with its own design and timeline; this repo is the pragmatic path and can be deprecated if core ever supports it.

Initial scope:

• A namespaced EnvironmentConfig CRD under a new API group, environmentconfigs.crossplane.io/v1alpha1, distinct from the cluster-scoped apiextensions.crossplane.io one, with the same schemaless data contract.
• A lightweight controller that marks instances Ready — composed resources need a Ready signal, so this is what lets producers compose the CRD without an AlwaysReady check in every Composition.
• Companion to function-environment-configs, which will gain (as planned follow-up in that repo) a configurable apiVersion/kind + namespace selector, defaulting to today's cluster-scoped kind, to load these.

Possible future improvements:

• Server-side aggregation: the controller resolves label/name selectors across EnvironmentConfigs and materializes a merged result in status.data, moving that work out of the function for the cases that don't depend on the consuming XR.
• A cluster-scoped variant, so the provider can offer both scopes.
• If core ever chooses to move EnvironmentConfig out of tree, this repo could inform or host that — but deprecating a core API is explicitly out of scope here and would be raised separately in crossplane/crossplane.

Non-goals: it is not a managed-resource provider for any external API; it has no ProviderConfig and reconciles no external system. We use the provider package type purely as the CRD-delivery mechanism.

Initial maintainer team (GitHub usernames)

• @phisco — maintainer of function-environment-configs and Crossplane maintainer (Upbound)
• @tenstad — author of feat request: namespace scoped EnvironmentConfig crossplane-contrib/function-environment-configs#105 and the originating use case

Description of the maintainer team's long term commitment to the extension

@phisco already maintains function-environment-configs and intends to keep doing so for the foreseeable future; this provider is a thin companion that evolves with it, so the marginal maintenance cost is small. @tenstad brings the originating use case and has agreed to co-maintain, giving the project more than one active maintainer from the start. We commit to keeping it compatible with current Crossplane releases, triaging issues and PRs, and cutting releases alongside the function. If at any point the team can no longer maintain it, we'll work with the steering committee to find new maintainers or archive it cleanly.

[bobh66]

This is not an argument against this concept, more a question about long-term direction.

We also use (cluster scoped) EnvironmentConfigs extensively for sharing information across composites, since that's all that was available when we started. Given the advent of the "RequiredResources" concept I've been wondering if it would be "better" to look up the composite resource directly using the "required resources" functionality of the pipeline and pull the desired information directly from it's status fields. That eliminates the need for the composite to publish the information in a dedicated EnvironmentConfig and also removes a step from the pipeline since function-environment-config also becomes unnecessary.

I don't know that there is a right answer, both ways will definitely work. I'm just curious if there are specific reasons for using one method or the other.

[tenstad]

Yeah, it should definitely be possible to fetch other resources from the same namespace as the composite resource. Both in https://github.com/crossplane-contrib/function-extra-resources (see #61) and the built-in https://docs.crossplane.io/v2.3/composition/compositions/#bootstrap-requirements.

However, I still think there is a place for EnvironmentConfig and added an example in crossplane-contrib/function-environment-configs#105 (comment).