status.externalRef
should be used as the GCP identifier of the Config Connector resource.
-
Config Connector should assign the
status.externalRef
value when it initially acquires or creates the GCP resource. -
Config Connector should use
status.externalRef
as the GCP identifier to retrieve, update and delete (if applicable) the resource. -
Config Connector should validate the
spec
corresponding identifiers (i.e.spec.projectRef
spec.location
,spec.resourceID
) based onstatus.externalRef
. -
The
status.externalRef
value can be used as the resource reference<kind>Ref.External
-
Config Connector shall not write the Direct resources' resource ID back to the
spec.resourceID
field. Only users should configure thespec
fields.1
type <Kind>Status struct {
/* A unique specifier for the <Kind> workerpool resource in GCP.*/
ExternalRef *string json:"externalRef,omitempty"
...
}
The status.externalRef
shall use the cloud asset inventory as reference to build its value. The service domain can be omitted.
- If a resource has multiple asset inventory, we choose the newer one in the resource name format list (normally the bottom ones).
- If a resource is not supported in the asset inventory, we shall refer to the resources’ REST API references to use the resource path.
-
If a resource does not let user to specify the name or identifier, but its GCP service assigns an ID in the HTTP response, the Direct reconciler will use the service generated ID to build the
status.externalRef
, but not write back to thespec.resourceID
. -
If user specifies the service-generated ID in the
spec.resourceID
field, the Direct reconciler will acquire the resource if thestatus.externalRef
is not assigned.
The existing TF-based and DCL-based reconciliation treats the spec.resourceID
as the single Source of Truth to identify a GCP resource. It writes back the spec.resourceID
after reconciliation. Here are the known problems. Config Connector will keep the bahavior of these resources, until they are migrated to the Direct reconciler.
Footnotes
-
Existing Terraform-based or DCL-based resources still have Config Connector written back to the
spec.resourceID
field for backward compatibility reasons. ↩