Enable Namespace as an optional field in TypedReference

[diviner524]

Description of your changes

Added support for namespace scoped objects in TypedReference, so we can introduce general namespace scoped resource in the resources list of composition. This change is backward compatible with existing implementation and does not require any updates from existing providers.

This also requires some changes in the main Crossplane repo after the runtime is updated. I have created a corresponding draft PR to demonstrate the idea:

crossplane/crossplane#4606

Fixes #251

I have:

• Read and followed Crossplane's [contribution process].
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Some manually testing with namespace scoped objects like ConfigMap.

For example, a Composition like below will help to update a namespace scoped ConfigMap with a redisHost URL from the status of certain CompositeResources. This will then enable workloads (like Deployments/StatefulSets) under the same namespace to consume the data from ConfigMap.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
...
spec:
...
  resources:
  - name: configmap
    base:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        namespace: "some-namespace"
    patches:
    - type: FromCompositeFieldPath
      fromFieldPath: status.redisHost
      toFieldPath: data.redisHost

[negz]

I'm not sure this is something we want to support.

Today, Crossplane is designed to allow you to compose Crossplane managed resources (MRs). This is an intentional constraint. The consistent API shape and behaviors of these MRs makes Crossplane easier to reason about, both for end-users and Crossplane maintainers.

I appreciate that this is just a small change. What I am concerned about is the "slippery slope" - that folks will begin to use Crossplane as a composition layer for arbitrary Kubernetes resources and we as maintainers will end up on the hook for trying to make that a good experience.

[jbw976]

Here is some historical related discussion and thinking around this topic that is helpful for context and understanding more nuances of the impact of this type of change: crossplane/crossplane#1730

edit: link to the correct issue 🤪

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This pull request has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Adding a comment starting with /fresh will mark this PR as not stale.

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This pull request has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Adding a comment starting with /fresh will mark this PR as not stale.

[negz]

I think the spirit of this PR is / will be addressed by Crossplane v2 (see proposal) which'll allow composing namespaced resources.

[diviner524]

I think the spirit of this PR is / will be addressed by Crossplane v2 (see proposal) which'll allow composing namespaced resources.

Thanks for sharing @negz.

Adding @justinsb, @yuwenma, @cheftako FYI.