Crossplane handles much of the operations to adopt existing infrastructure and begin managing it. However, it cannot determine what resources a user wants to adopt from their provider without fairly significant manual intervention by the user in some cases. It would be nice for the libraries used in providers to also be able to be used to generate CRs for existing infrastructure types. I imagine the experience looking something like this:
crossplane-cli provides extension points for plugins to be installed. Maybe they are installed automatically if you use the CLI to install the provider into your cluster (see using labels on CRDs below).
The provider plugins satisfy interfaces for getting resources from the provider via simple CLI commands.
A user may list existing infrastructure using the CLI, then choose resources they wish to be rendered and applied as CRs for Crossplane to gain control of.
Much of this effort for providers would just be re-purposing existing code and supplying the appropriate endpoints. In fact, it may be possible to handle this as labels on the CRDs. For instance, a CRD for CloudSQL could include a label like get.cli.crossplane.io/endpoint: https://www.googleapis.com/sql/v1beta4/projects/{project}/instances.
Crossplane handles much of the operations to adopt existing infrastructure and begin managing it. However, it cannot determine what resources a user wants to adopt from their provider without fairly significant manual intervention by the user in some cases. It would be nice for the libraries used in providers to also be able to be used to generate CRs for existing infrastructure types. I imagine the experience looking something like this:
Much of this effort for providers would just be re-purposing existing code and supplying the appropriate endpoints. In fact, it may be possible to handle this as labels on the CRDs. For instance, a CRD for
CloudSQLcould include a label likeget.cli.crossplane.io/endpoint: https://www.googleapis.com/sql/v1beta4/projects/{project}/instances.