Merge lp:~rvb/gomaasapi/gomaasapi-bug-1384001 into lp:gomaasapi
Status: | Merged |
---|---|
Approved by: | Ian Booth on 2014-10-27 |
Approved revision: | 63 |
Merged at revision: | 58 |
Proposed branch: | lp:~rvb/gomaasapi/gomaasapi-bug-1384001 |
Merge into: | lp:gomaasapi |
Diff against target: |
195 lines (+137/-3) 3 files modified
client.go (+50/-3) client_test.go (+50/-0) testing.go (+37/-0) |
To merge this branch: | bzr merge lp:~rvb/gomaasapi/gomaasapi-bug-1384001 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | Approve on 2014-10-27 | ||
Juju Engineering | 2014-10-27 | Pending | |
Review via email:
|
Commit message
Retry requests that result in a 503 response with the Retry-After header set.
Description of the change
This works in tandem with https:/
- 60. By Raphaël Badin on 2014-10-27
-
Lint fixes.
- 61. By Raphaël Badin on 2014-10-27
-
Update comment.
- 62. By Raphaël Badin on 2014-10-27
-
Review fixes.
- 63. By Raphaël Badin on 2014-10-27
-
Retry more.
Julian Edwards (julian-edwards) wrote : | # |
Small point of order - MAAS doesn't set the Retry-After header (yet).
Julian Edwards (julian-edwards) wrote : | # |
Ah my bad, saw the maas change you made after I had written that.
Andrew Wilkins (axwalk) wrote : | # |
I think it'd be good to have an option to handle this outside of gomaasapi as well. In Juju, the provisioner runs in a single goroutine (there are good reasons for that) and so retrying a single request will block others. It'd be good to just reschedule the provisioning for the failed one.
For other operations (e.g. releasing all nodes) I think this behaviour would be fine.
- 64. By Raphaël Badin on 2014-10-28
-
Restore body before issuing request.
Ian Booth (wallyworld) wrote : | # |
@Andrew,
The new behaviour in here now matches what goose does. When Openstack's rate limit is exceeded, a 403 response comes back and goose will retry after the time set by the retry-after header. This is independent of what request is being made. I think this is ok given that machine provisioning generally takes a while anyway, and adding in a few retries hopefully won't materially affect the total time. Not that there's not scope to discuss if this could be improved across the board.
My eyes are bleeding, but otherwise it seems okay.