[
https://issues.apache.org/jira/browse/JCLOUDS-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16008251#comment-16008251
]
Ignasi Barrera commented on JCLOUDS-1296:
-----------------------------------------
Hmmm it is not the only operation that puts a resource in a "busy" state. For
example, when attaching a VM to a load balancer, or performing other operations
that affect the NICs subnets, the same problem appears.
If we are going to introduce a "retry on busy" behavior we should build a
generic one. I've also noticed these errors often are returned as a 429 and our
code interprets it (wrongly) as rate limit errors, we should improve that too
if we are implementing a generic retry mechanism.
> Azure ARM SubnetApi retry handler for "HTTP/1.1 409 Conflict"
> -------------------------------------------------------------
>
> Key: JCLOUDS-1296
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1296
> Project: jclouds
> Issue Type: Bug
> Affects Versions: 2.0.1
> Reporter: Svetoslav Neykov
> Labels: azurecompute-arm
>
> When doing changes on a subnet (e.x. adding one) the parent virtual network
> is set to the "updating" state. While in this state any other request to
> change a subnet will fail with "409 Conflict" response. The response body
> contains:
> {noformat}
> {
> "error": {
> "code": "AnotherOperationInProgress",
> "message": "Another operation on this or dependent resource is in
> progress. To retrieve status of the operation use uri:
> https://management.azure.com/subscriptions/<subscription
> id>/providers/Microsoft.Network/locations/westeurope/operations/b83705f8-77d2-4e68-9ac6-647db146106b?api-version=2017-03-01.",
> "details": []
> }
> }
> {noformat}
> The request-response pair:
> {noformat}
> 2017-05-12 12:34:40,027 DEBUG 106 j.headers [ager-NxN8ADpS-26] >> PUT
> https://management.azure.com/subscriptions/<subscription
> id>/resourcegroups/jclouds-westeurope/providers/Microsof
> t.Network/virtualNetworks/network-security-vnet-o6sjw3y2cj/subnets/lb-tier?api-version=2017-03-01
> HTTP/1.1
> 2017-05-12 12:34:40,027 DEBUG 106 j.headers [ager-NxN8ADpS-26] >> Accept:
> application/json
> 2017-05-12 12:34:40,027 DEBUG 106 j.headers [ager-NxN8ADpS-26] >>
> Content-Type: application/json
> 2017-05-12 12:34:40,027 DEBUG 106 j.headers [ager-NxN8ADpS-26] >>
> Content-Length: 48
> 2017-05-12 12:34:40,535 DEBUG 106
> o.j.i.ContentMetadataCodec$DefaultContentMetadataCodec [ager-NxN8ADpS-26]
> Invalid Expires header (-1); should be in RFC-1123 format; treating as
> already expired: Error
> parsing data at 0
> 2017-05-12 12:34:40,536 DEBUG 106 o.j.h.o.OkHttpCommandExecutorService
> [ager-NxN8ADpS-26] Receiving response 1361047216: HTTP/1.1 409 Conflict
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] << HTTP/1.1
> 409 Conflict
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] << Date: Fri,
> 12 May 2017 09:34:39 GMT
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> OkHttp-Received-Millis: 1494581680535
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> OkHttp-Selected-Protocol: http/1.1
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> OkHttp-Sent-Millis: 1494581680029
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] << Pragma:
> no-cache
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] << Server:
> Microsoft-HTTPAPI/2.0
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] << Server:
> Microsoft-HTTPAPI/2.0
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> Strict-Transport-Security: max-age=31536000; includeSubDomains
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> x-ms-correlation-request-id: a5fe53d2-dfd6-4381-a73b-37457f721a0b
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> x-ms-ratelimit-remaining-subscription-writes: 1195
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> x-ms-request-id: 0820fa55-9e4f-45b5-9b88-f71ea1fcb731
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> x-ms-routing-request-id:
> CANADAEAST:20170512T093440Z:a5fe53d2-dfd6-4381-a73b-37457f721a0b
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> Cache-Control: no-cache
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> Content-Type: application/json; charset=utf-8
> 2017-05-12 12:34:40,536 DEBUG 106 j.headers [ager-NxN8ADpS-26] <<
> Content-Length: 414
> 2017-05-12 12:34:40,537 DEBUG 106 j.headers [ager-NxN8ADpS-26] << Expires:
> Thu Jan 01 02:00:00 EET 1970
> {noformat}
> While this could be handled at the application level, would be useful to add
> subnet-specific retry logic to retry the requests on the jclouds side.
> Details for the behaviour can be found in the "MS-NCNBI (Network Controller
> Northbound Interface)" spec, section "1.3.3 Concurrent Operations". It's not
> really clear but I assume "parent-child tree" there refers to a virtual
> network and its children subnet resources.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
