Open resmo opened 4 months ago
I've been noticing some weird, unexpected behavior when testing this, but I think it's because of the platform not being very responsive. Even when things VPC2 detach mechanism isn't instantaneous which is why we have to use retries in the terraform provider to check and attempt the delete/detach.
All that said, I was able to create via cURL, then detach using the examples that you provided. But, like I said, there was a good 10-15 second delay before it reflected that that node was detached.
@optik-aper I see, thanks for this information. A couple questions though: is this just a VPC2 related thing or would it make sense to implement a generic "retry to see vpc changed" function for VPC1 as well? I'm assuming VPC1 will be deprecated in the future, do you have a timeline for this yet?
The retry is specific to VPC2 due to how the platform detects changes and applies them. VPC1 doesn't have this same mechanism so should be effective immediately. I don't know if/when VPC1 will be deprecated but do know that it's currently being used by VKE so I don't think it's going anywhere anytime soon.
I did some more tests and might have found the issue I am experiencing:
$ vultr-cli vpc2 list
ID DATE CREATED REGION DESCRIPTION IP BLOCK PREFIX LENGTH
5df03f12-fc11-45ca-a0c2-ac6b08aa543e 2024-03-12T11:24:02-04:00 ams ansible-test-82586263-diode_instance_vpc2_1 192.168.22.0 24
664da4eb-8857-4b5a-bc1f-02eb04ddb716 2024-03-12T11:24:03-04:00 ams ansible-test-82586263-diode_instance_vpc2_2 192.168.99.0 24
$ vultr-cli instance vpc2 list 8bfb02eb-75d8-436d-a30f-1a9af088728d
ID MAC ADDRESS IP ADDRESS
5df03f12-fc11-45ca-a0c2-ac6b08aa543e 5a:01:04:ce:df:3d 192.168.22.3
NOTE: the order of the IDs seems relevant!
The first list item is the ID of the VPC2 already exists!!
curl "https://api.vultr.com/v2/instances/8bfb02eb-75d8-436d-a30f-1a9af088728d" \
-X PATCH \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"attach_vpc2": [
"5df03f12-fc11-45ca-a0c2-ac6b08aa543e"
"664da4eb-8857-4b5a-bc1f-02eb04ddb716",
]
}'
--> VPC2 with ID 664da4eb-8857-4b5a-bc1f-02eb04ddb716 never gets attached.
if we change the order:
curl "https://api.vultr.com/v2/instances/8bfb02eb-75d8-436d-a30f-1a9af088728d" \
-X PATCH \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"attach_vpc2": [
"664da4eb-8857-4b5a-bc1f-02eb04ddb716",
"5df03f12-fc11-45ca-a0c2-ac6b08aa543e"
]
}'
--> the VPC2 gets attached, but the VPC2 gets node_status=failed
:
$ curl "https://api.vultr.com/v2/instances/8bfb02eb-75d8-436d-a30f-1a9af088728d/vpc2" \
-X GET \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json"
{"vpcs":[{"id":"5df03f12-fc11-45ca-a0c2-ac6b08aa543e","mac_address":"5a:01:04:ce:df:3d","ip_address":"192.168.22.3","node_status":"active"},{"id":"664da4eb-8857-4b5a-bc1f-02eb04ddb716","mac_address":"5a:02:04:ce:df:3d","ip_address":"192.168.99.3","node_status":"failed"}],"meta":{"total":2,"links":{"next":"","prev":""}}}%
$ curl "https://api.vultr.com/v2/instances/8bfb02eb-75d8-436d-a30f-1a9af088728d" \
-X PATCH \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"attach_vpc2": [
"664da4eb-8857-4b5a-bc1f-02eb04ddb716"
]
}'
--> works
$ curl "https://api.vultr.com/v2/instances/8bfb02eb-75d8-436d-a30f-1a9af088728d/vpc2" \
-X GET \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json"
{"vpcs":[{"id":"5df03f12-fc11-45ca-a0c2-ac6b08aa543e","mac_address":"5a:01:04:ce:df:3d","ip_address":"192.168.22.3","node_status":"active"},{"id":"664da4eb-8857-4b5a-bc1f-02eb04ddb716","mac_address":"5a:02:04:ce:df:3d","ip_address":"192.168.99.3","node_status":"active"}],"meta":{"total":2,"links":{"next":"","prev":""}}}%
For detaching it seems like it is the same.
Oh, interesting. Let me test this out and see what it's doing. Thanks for the additional details!
@optik-aper Hi Micheal, were you able to reproduce?
Describe the bug Detaching VPC2 does not work, even though the commands was successful (might be an api issue):
I tried several ways:
To Reproduce Steps to reproduce the behavior:
list vpc2
create an instance with vpc2 attached:
check
Expected behavior
vpc2 detached
Additional context
also seeing this issue in ansible vultr collection https://github.com/vultr/ansible-collection-vultr/pull/118
$ vultr-cli version
Vultr-CLI v3.0.1