docs: default value of `allowCRDDeletion` is false, which may cause confusion.

[kennygt51]

Documentation Issue

Location:
Getting Started / examples
https://kro.run/docs/getting-started/Installation
https://kro.run/docs/getting-started/deploy-a-resource-graph-definition

Current State:
When deleting the RGD, CRDs deployed by the RGD are not deleted automatically.
Therefore, when deleting a RGD, users need to manually delete the CRDs deployed by the RGD.

This is because the default value of allowCRDDeletion is false.
ref:

kro/cmd/controller/main.go

Line 95 in b869a81

flag.BoolVar(&allowCRDDeletion, "allow-crd-deletion", false, "allow kro to delete CRDs")

Getting Started installation guide doesn't include this setting.
I think a lot of users may become confused during testing.
Myself as well, As a user, I experienced some confusion while working through some examples.

Suggested Changes:
Consider one of the following approaches:

• Change the default option for allowCRDDeletion to true
• Add a note to the Getting Started guide and some README of examples:
  • "allowCRDDeletion is set to false by default, CRDs must be manually deleted"

Once the necessary corrections are identified and the policy is decided, I will take care of it on my side.

[bschaatsbergen]

Thanks for raising this, and for taking the time to walk through the examples.

On the CRD deletion behavior: this is intentional for now. An RGD is meant to behave more like a module or building block that a platform team publishes. If that artifact disappears (gets renamed, moved, or accidentally deleted), we generally don’t want all resources that depend on it to be cleaned up automatically. In most real-world setups, that would be surprising and quite destructive.

That’s why allowCRDDeletion defaults to false: it’s a guardrail to prevent unintended cascading deletions if the RGD itself goes away.

That said, I completely agree that this isn’t obvious when going through the Getting Started docs, and it can definitely feel confusing during early testing. Adding a call-out or note in the installation and examples sections would help set expectations much better.

We’re actively looking into ways to improve the developer experience and the lifecycle management of RGDs and their instances. If you have any suggestions, we’re all ears.

Thanks again for surfacing this, a docs update would be very welcome!

[kennygt51]

Thank you for your reply and detailed explanation !!
I understand that RGS is like a module or a set of building blocks to provide streaming-aligned teams.

Thanks again for pointing this out — a docs update would be very welcome!

Thanks. I’ll create a PR to add a note to a few pages.

[tjamet]

Thanks for sharing your thoughts @kennygt51
That's a topic discussed here #763 if you want to contribute there