search

crossplane / crossplane-runtime

A set of libraries for writing Crossplane controllers.
https://crossplane.io
Apache License 2.0
158 stars 101 forks source link

Support Namespaced Managed Resources #251

Open ctrox opened 3 years ago

ctrox commented 3 years ago

What problem are you facing?

Right now, crossplane-runtime does not formally support namespaced managed resources. It kind of works and only breaks if certain features are used. Because we (my team and I) were unaware that this was unintentional, we simply started using it.

How could Crossplane help solve your problem?

It would be great if crossplane-runtime formally supported namespaced managed resources. I initially thought this was a bug, but it turns out this was simply not intended to work. But most of crossplane-runtime already works when using a namespaced managed resource, just by instructing kubebuilder: +kubebuilder:resource:scope=Namespaced. While we are aware of all the other Crossplane constructs that allow to have namespaced resources (compositions, publications etc.), it introduces a lot of configuration overhead, where we just could use the managed resource directly for some resources.

After a few glances at the code, it seems only a few changes here and there would be required to make references, externalName etc. work properly with namespaced resources. If you are not totally opposed to this, I can offer to contribute the required changes.

negz commented 3 years ago

Thanks for raising this! While I agree it would be technically straightforward to support namespaced managed resources, I'm quite wary to do so primarily out of concern about the cognitive and logical burden it would introduce - e.g. both Crossplane users and Crossplane code would need to be able to account for whether a particular managed resource was namespaced or cluster scoped. How would a provider author determine whether their managed resource should be namespaced or cluster scoped?

I'd love to hear more about your use cases for namespaced managed resources. As you point out, Crossplane's approach is to encourage you to abstract your managed resources via an XR and to offer a namespaced claim.

nekto0n commented 3 years ago

Hey there! One possible user story could go like this:

I am on the infrastructure team at my company and we want to offer Azure (AKS in particular) as a service for engineers via crossplane controller. We want to be able to apply policies, grant permissions, attach quotas and perform cost and audit control.

It seems that logical to achieve this by using namespaces to get k8s native tools to work (RBAC, etc). Does that sound like a legit case?

hikhvar commented 3 years ago

For our usecase namespaced managed resources would allow us to easily delete all resources created for a deployment. We create a namespace per application. To remove an application we simply delete the namespace and all resources for that application are gone. With non-namespaced crossplane resources we must also label the resources and must know which resources are created by the application.

negz commented 2 years ago

I am on the infrastructure team at my company and we want to offer Azure (AKS in particular) as a service for engineers via crossplane controller. We want to be able to apply policies, grant permissions, attach quotas and perform cost and audit control.

Crossplane is designed to support this via resource claims (which are namespaced). The idea is that you'd offer AKS as a service via a claim, not via the 'raw' managed resources.

For our usecase namespaced managed resources would allow us to easily delete all resources created for a deployment. We create a namespace per application. To remove an application we simply delete the namespace and all resources for that application are gone. With non-namespaced crossplane resources we must also label the resources and must know which resources are created by the application.

FWIW, I believe this is also something you could do with claims. Deleting a namespace containing Crossplane composite resource claims (XRCs) would cause the claims to be deleted, which in turn would delete the XR and all composed resources.

Generally, I don't think we'll be adding support for namespaced managed resources - at least not without a major version bump. I will leave this issue open to gather more feedback.

nekto0n commented 2 years ago

Crossplane is designed to support this via resource claims (which are namespaced). The idea is that you'd offer AKS as a service via a claim, not via the 'raw' managed resources.

Got it! Please correct me if I got the idea wrong: if infrastructure owners want to expose all available AWS resources as claims, they need to manually create corresponding claim CRDs. Are there any means to automate this procedure?

luebken commented 2 years ago

Mr @benagricola has created a generator https://github.com/benagricola/crossplane-composition-generator

It's on my to do list to give it a try.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 2 months ago

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue 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. Leaving a comment starting with /fresh will mark this issue as not stale.