You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As exemplified in crossplane-contrib/provider-upjet-aws#661, current managed resource tests we run using uptest do not cover the import scenarios (importing existing infrastructure under Crossplane management). This is relevant not only to observe-only resources but also when the established ephemeral Terraform workspace is lost due to provider pod restart.
How could Uptest help solve your problem?
We need to make sure that the managed resource's external-name configuration can properly uniquely identify the external resource, i.e., the config.ExternalName.GetIDFn can properly construct the Terraform ID for the existing resource. We should add import tests so that both provider restart scenarios and observe-only resource scenarios are properly tested. Some alternatives could be:
Employ observe-only resources: After a resource is successfully provisioned with the spec.deletionPolicy == Orphan (i.e., when the MR is deleted, the external resource will be orphaned), we could import the resource as observe-only (i.e., spec.managementPolicy == ObserveOnly) and assert that the associated external-resource can successfully be found. However, we would also like to make sure that we can properly delete the external resource.
Similar to the approach above but without using the concept of an observe-only resource, we could provision a managed resource with spec.deletionPolicy == Orphan, store a copy of the managed resource manifest and recreate the managed resource, this time with spec.deletionPolicy == Delete and assert that the associated external-resource can successfully be found and the managed resource acquired the Read == true status condition with the previous ID. We can then assert that the second managed resource with spec.deletionPolicy == Delete can successfully be deleted.
A shortcut could be to provision a managed resource and after it acquired the Ready == true, Synced == true status conditions after the late-initialization (what uptest currently asserts), remove the Terraform workspace corresponding to the managed resource, remove the Ready == true, Synced == true status conditions and force a reconcile of the resource. We can then assert that the managed resource properly re-acquires the Ready == true, Synced == true status conditions to make sure that the Terraform ID for the external resource can properly be reconstructed with the supplied external-name configuration.
...
The text was updated successfully, but these errors were encountered:
What problem are you facing?
As exemplified in crossplane-contrib/provider-upjet-aws#661, current managed resource tests we run using uptest do not cover the import scenarios (importing existing infrastructure under Crossplane management). This is relevant not only to observe-only resources but also when the established ephemeral Terraform workspace is lost due to provider pod restart.
How could Uptest help solve your problem?
We need to make sure that the managed resource's external-name configuration can properly uniquely identify the external resource, i.e., the config.ExternalName.GetIDFn can properly construct the Terraform ID for the existing resource. We should add import tests so that both provider restart scenarios and observe-only resource scenarios are properly tested. Some alternatives could be:
spec.deletionPolicy == Orphan
(i.e., when the MR is deleted, the external resource will be orphaned), we could import the resource as observe-only (i.e.,spec.managementPolicy == ObserveOnly
) and assert that the associated external-resource can successfully be found. However, we would also like to make sure that we can properly delete the external resource.spec.deletionPolicy == Orphan
, store a copy of the managed resource manifest and recreate the managed resource, this time withspec.deletionPolicy == Delete
and assert that the associated external-resource can successfully be found and the managed resource acquired theRead == true
status condition with the previous ID. We can then assert that the second managed resource withspec.deletionPolicy == Delete
can successfully be deleted.Ready == true, Synced == true
status conditions after the late-initialization (what uptest currently asserts), remove the Terraform workspace corresponding to the managed resource, remove theReady == true, Synced == true
status conditions and force a reconcile of the resource. We can then assert that the managed resource properly re-acquires theReady == true, Synced == true
status conditions to make sure that the Terraform ID for the external resource can properly be reconstructed with the supplied external-name configuration.The text was updated successfully, but these errors were encountered: