tencentcloud-cvm Failed to wait for instance ready: instance(ins-xxxx) not exist #6
Labels
Comments
ghost
mentioned this issue
|
Hello @Virain |
|
Hello @likexian |
|
Hello @Virain |
|
@likexian Now the same problem occurs again. This time, after packaging multiple images successfully, the error invalidinstanceid.notfound occurs again. It seems that CVM was not created successfully, packer could not get the instance, and I could not see the creation of CVM from Tencent cloud console.Does the API have restrictions on creating CVMs, which makes it impossible to create CVMs after creating a certain number of CVMs? |
|
@Virain not sure if it’s the same issue that I face. Try changing the instance name? |
Yep,Change the instance name to create |
|
Yes, try change the instance name, when there are multiple buildings, uses difference instance name. |
|
@likexian it seems like this issue is safe to close. Please advise if there is any work to do here. |
|
Hello @nywilken please close. |
|
Thank you for supporting this issue @likexian closing at your request. |
|
This is still happening. Started happening randomly while I was building various images: No instances is actually created. |
Jalle19
pushed a commit
to Jalle19/packer-plugin-tencentcloud
that referenced
this issue
Oct 22, 2024
The purpose of ClientToken is to ensure request idempotency in case the request needs to be retried. This means the value must be unique for all unique RunInstances API calls. When building a template that references the same source multiple times (or multiple different sources), many calls to RunInstances are made. However, the same auto-generated instance name was used as "ClientToken". This changes ClientToken to be unique regardless of whether the user has supplied a unique "instance_name" for each source/build. Fixes hashicorp#6
Jalle19
added a commit
to Jalle19/packer-plugin-tencentcloud
that referenced
this issue
Oct 22, 2024
The purpose of ClientToken is to ensure request idempotency in case the request needs to be retried. This means the value must be unique for all unique RunInstances API calls. When building a template that references the same source multiple times (or multiple different sources), many calls to RunInstances are made. However, the same auto-generated instance name was used as "ClientToken". This changes ClientToken to be unique regardless of whether the user has supplied a unique "instance_name" for each source/build. Fixes hashicorp#6
Jalle19
added a commit
to Jalle19/packer-plugin-tencentcloud
that referenced
this issue
Oct 22, 2024
The purpose of ClientToken is to ensure request idempotency in case the request needs to be retried. This means the value must be unique for all unique RunInstances API calls. When building a template that references the same source multiple times (or multiple different sources), many calls to RunInstances are made. However, the same auto-generated instance name was used as "ClientToken". This changes ClientToken to be unique regardless of whether the user has supplied a unique "instance_name" for each source/build. Fixes hashicorp#6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue was originally opened by @Virain as hashicorp/packer#10396. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.
Overview of the Issue
I used the packer to package the image. An ansible syntax error occurred. The packer stopped running and deleted the instance. After running the packer again, the prompt failed to wait for instance ready: instance (INS XXX) not exist
packer 1.6.5
error logs
The text was updated successfully, but these errors were encountered: