Use generic resource config plumbing to do common resource customizations

[sboschman]

Description of your changes

This PR introduces the same generic resource configuration setup as used by aws/gcp jet providers (config/providers.go and config/overrides.go). This should make it easier to do common resource customizations.

Common customizations introduced with this PR:

• restructure/rename the provided CRDs to a hopefully more sensible names
• changed grouping for some resources to allow cluster/project refs without go cyclic deps
• use IdentifierFromProvider for some resources
• create cluster_id and project_id references

The api version of manual configured Cluster resource is bumped to v1alpha2, the other resources remain at v1alpha1. The new api reference can be inpsected here

I have:

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

How has this code been tested

ProviderConfig is unchanged and remains at v1alpha1.

Examples tested:

• authconfig, Rancher UI shows Auth Provider as expected
• catalog, Rancher API browser shows item as expected
• cloud credential, Rancher UI shows cloud credentials as expected
• project, Project shows up in Rancher UI
• namespace, Namespace is created under the example project

[sboschman]

@ytsarev hopefully yo have a few mins spare to look at it

[sboschman]

Thanks a lot for all the tests and clarifications, I think we can merge this one.

Additional changes to fix individual resources can be separate PRs imo, as it seems some resources are a little bit more 'complex' and require additional config.

For example, managing secrets throws CannotObserveExternalResource", "message": "cannot run refresh: refresh failed: Getting secret V2: Cluster ID and/or Secret V2 ID is nil

Or importing a cluster starts a reconcile like it owns the cluster "reason": "CannotUpdateExternalResource", "message": "cannot apply: apply failed: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=InvalidBodyContent, message=must have at least one node pool]

[ytsarev]

@sboschman could you please create an Issue for the last one?

[sboschman]

Did some digging into the cluster error, reason: https://github.com/rancher/terraform-provider-rancher2/issues/895

Cluster is imported with Crossplane into Rancher, so cluster lifecycle is managed outside Crossplane and Rancher. Rancher does place some annotations, which are returned by terraform (state). One of these annotations is an internal sync timestamp for Rancher itself. Crossplane detects config drift on this annotation and tries to resync the cluster resource. The terraform apply runs into the terraform-provider-rancher2 issue mentioned above.

So, problem 1 is that imported clusters can not be modified as a result of this bug. Even though changing the description (tested as well) and modifying annotations or labels should be allowed. Upstream problem imo, not something we can fix in the crossplane provider.

Problem 2 is the drift detection of labels/annotations which Crossplane does not control. Resetting the timestamp annotation by Crossplane to a previous value is a no go, regardless if this triggers the bug of problem 1. I guess the solution here should be ignoring (LateInitializer.IgnoredFields) all labels and annotations like xxx.cattle.io/yyy. As I don't want to hardcode labels/annotations I just happen to see on my cluster, it should be some sort of regex/wildcard match.

[sboschman]

opened #13 for this cluster issue

[ytsarev]

@sboschman cool, thanks, merging this one in