-
Notifications
You must be signed in to change notification settings - Fork 122
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
[Bug]: Crossplane forgets an already created resource by itself (Subnet, SubnetCidrReservation, SecurityGroupRule, NetworkACLRule) #1482
Comments
Another example:
the external-name is missing so the provider doesn't know that it created the resource already. |
|
@ulucinar this seems to be a timing issue where the external-name annotation is never added to the resource, or the update fails and the name gets lost is the process. Can you think of anything that we could try to collect more information, or are there known upjet issues in this area that need to be addressed? Thanks! |
Related issues and code: |
We face the same issue as well, it happens randomly and very annoying... |
Opened the the issue and PR for this at the TF provider repo: hashicorp/terraform-provider-aws#39741 |
Is there an existing issue for this?
Affected Resource(s)
ec2.aws.upbound.io/v1beta1 - Subnet
ec2.aws.upbound.io/v1beta1 - SubnetCidrReservation
ec2.aws.upbound.io/v1beta1 - SecurityGroupRule
ec2.aws.upbound.io/v1beta1 - NetworkACLRule
Resource MRs required to reproduce the bug
Steps to Reproduce
We were not able to deterministically reproduce this issue. This issue happens randomly when creating multiple resources of the above.
What happened?
Sometimes when we create a MR via Crossplane the
tfID
returned from AWS after a successful resource creation is not saved to the"crossplane.io/external-name"
annotation. During the next reconciliation a Diff is again detected with the same content as previously. Therefore, Crossplane sends another request to AWS but it fails because the resource already exists on AWS side.See
subnet-create-fail.log
for further details. We observed the same behavior with the creation of Subnet, SubnetCidrReservation, SecurityGroupRule, NetworkACLRule.We also provided a working example
subnet-create-ok.log
. As you can see the same MR manifest sometimes provides a failed result.Relevant logs:
Relevant Error Output Snippet
Crossplane Version
v1.16.0
Provider Version
v1.11.0; v1.13.0
Kubernetes Version
v1.29.7-eks-a18cd3a
Kubernetes Distribution
EKS
Additional Info
FYI:
@janosdubovszky
@bobh66
The text was updated successfully, but these errors were encountered: