toumorokoshi
commented
3 years ago Hi! Definitely agreed that being able to provide better management of multiple related CRs is a good thing.
If there was a standardized definition (such as from a Kubernetes SIG), I think that makes a lot of sense for Config Connector to adopt.
Are the guidelines you linked aligning to some sort of Kubernetes OSS standard? If it's proprietary, it doesn't seem right to add such annotations to a tool intended to be product-agnostic like Config Connector.
It is awesome that provisioning of various Google cloud managed services is getting Kubernetes-native support through CRDs.
Given that application developers can consume multiple managed services, they will end up working with multiple Custom Resources. We have been developing guidelines for simplifying creation of such multi-Custom Resource stacks. Particularly, https://github.com/cloud-ark/kubeplus/blob/master/Guidelines.md#12-add-platform-as-code-annotations-on-your-crd-yaml is focused on making it easy for application developers to discover static usage information and dynamic runtime information about Custom Resources.
I was wondering if it would be possible to add the annotations mentioned in the above guidelines to config-connector's CRD definitions? Especially, the 'composition' annotation can help with generating runtime composition tree of Kubernetes resources that are created for handling a particular Custom Resource instance.