feat request: namespace scoped EnvironmentConfig #105
Description
What problem are you facing?
After the change to namespace scoped composites and compositions i v2, it is no longer possible to create an EnvironmentConfig in a (namespaced) composition.
Indirectly creating a cluster scoped EnvironmentConfig, using an Object from provider-kubernetes, is painfull and goes against the move to namespace scoped resources.
Usecase
One usecase (mentioned on slack) is sharing values between composites, where one composition creates an EnvironmentConfig which the other one imports into its environment. This way, an id can be transferred from the status.atProvider of one managed resource to the spec.forProvider of another managed resource in a different composition.
An alternative is to expose the values in the status of the composite, and use function-extra-resources or required resources to read it in the other composition. However, this results in the end-user seeing what might be confusing internal details in the status of their composites.
How could this Function help solve your problem?
A namespace scoped EnvironmentConfig CRD could be created (either by Crossplane or the user), which this function would support loading into a composition environment. If created by Crossplane, EnvironmentConfigs.apiextensions.crossplane.io is already taken, and another apiGroup or kind would be needed.
The function would need to select between cluster and namespaced scoped EnvironmentConfig (default to cluster scoped), which could be a user defined apiVersion/kind selector as in function-extra-resources, or a hardcoded apiVersion/kind if the CRD is created/provided by Crossplane.
The function could support reading namespace scoped EnvironmentConfigs from any namespace, but should default to the same namespace as the composite resource is within.