lifecycle.prevent_destroy issue for resource groups: Instance trying to be destroyed after creation and we can see resources have SYNCED False after READY became True

[svscheg]

What happened?

During testing the resource groups we have an issue with lifecycle.prevent_destroy. List of resources:

• aws_appmesh_virtual_router
• aws_appmesh_virtual_gateway
• aws_appmesh_virtual_node
• aws_appmesh_virtual_service
• aws_appmesh_gateway_route
• aws_appmesh_route
• aws_directory_service_log_subscription
• aws_networkmanager_site_to_site_vpn_attachment
• aws_networkmanager_transit_gateway_peering

For example will take error for aws_appmesh_virtual_node (all another resources have the same problem) - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appmesh_virtual_node

Error message: message: 'observe failed: cannot run plan: plan failed: Instance cannot be destroyed: Resource aws_appmesh_virtual_node.serviceb1 has lifecycle.prevent_destroy set, but the plan calls for this resource to be destroyed. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or reduce the scope of the plan using the -target flag.'

How can we reproduce it?

Copy generated manifest, add missing dependancy aws_appmesh_mesh, try to apply manifest. yaml_output.txt virtualnode.yaml.txt

The following manifests can be used to reproduce the issue:

apiVersion: appmesh.aws.upbound.io/v1beta1
kind: VirtualNode
metadata:
  annotations:
    meta.upbound.io/example-id: appmesh/v1beta1/virtualnode
  labels:
    testing.upbound.io/example-name: serviceb1
  name: serviceb1
spec:
  forProvider:
    meshNameSelector:
      matchLabels:
        testing.upbound.io/example-name: simple
    region: us-west-1
    spec:
    - backend:
      - virtualService:
        - virtualServiceName: servicea.simpleapp.local
      listener:
      - portMapping:
        - port: 8080
          protocol: http
      serviceDiscovery:
      - dns:
        - hostname: serviceb.simpleapp.local

---

apiVersion: appmesh.aws.upbound.io/v1beta1
kind: Mesh
metadata:
  annotations:
    meta.upbound.io/example-id: appmesh/v1beta1/mesh
  labels:
    testing.upbound.io/example-name: simple
  name: simple
spec:
  forProvider:
    region: us-west-1

What environment did it happen in?

• Universal Crossplane Version:
• Provider Version:

[ezgidemirel]

TF registry documentation of this API group is misleading. When I created a virtual node resource, I noticed that the ID was a randomly generated UUID:

NAME                                           READY   SYNCED   EXTERNAL-NAME
       AGE
virtualnode.appmesh.aws.upbound.io/serviceb1   True    True     14cacdaf-1cac-4a50-8618-bbed3ed4
769a   3m37s

NAME                                 READY   SYNCED   EXTERNAL-NAME   AGE
mesh.appmesh.aws.upbound.io/simple   True    True     simple          29m

Therefore, we need to use config.IdentifierFromProvider in this group like in this PR.

[github-actions[bot]]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[github-actions[bot]]

This issue is being closed since there has been no activity for 14 days since marking it as stale. If you still need help, feel free to comment or reopen the issue!