Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Managed Resource Import Tests #92

Open
ulucinar opened this issue Apr 17, 2023 · 0 comments
Open

Managed Resource Import Tests #92

ulucinar opened this issue Apr 17, 2023 · 0 comments
Labels
enhancement New feature or request is:triaged
Milestone

Comments

@ulucinar
Copy link
Contributor

ulucinar commented Apr 17, 2023

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:

  • 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.
  • ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request is:triaged
Projects
None yet
Development

No branches or pull requests

2 participants