- modify BaseComputeService to make the 2 operations more similar
- remove overridden destroyNode and destroyNodesMatching from GoogleComputeEngineService
This makes dependencies consistent and eliminates warnings of the
form:
$M2_HOME/repository/org/apache/jclouds/driver/jclouds-slf4j/2.1.0-SNAPSHOT/jclouds-slf4j-2.1.0-SNAPSHOT.jar(org/jclouds/logging/slf4j/config/SLF4JLoggingModule.class): warning: Cannot find annotation method 'value()' in type 'AutoService': class file for com.google.auto.service.AutoService not found
Reference:
https://github.com/google/auto/tree/master/service#download
As all methods use POST we can not use the method to determine if funciton is idempotent.
We therefore set all as idempotent to nullify that check and add a custom
IOException retry handler to determine if commands should be retried on IOException.
The custom hander extends the BackoffLimitedRetryHandler, the current handler, so all other behaviour is not affected.
This does not retry any POST methods unless it's ACTION starts with 'Describe'. These functions are idempotent, and therefore safe to retry.
See JCLOUDS-1293
The intention is to use @SinceApiVersion for this purpose, but that
would affect a number of APIs, and we would want to have good test
coverage before merging that change (in
FormSignerUtils#getAnnotatedApiVersion). However, there is some issue
wth certain tests at resent that means we cannot successfully test
all APIs that make use of @SinceApiVersion in order to assure
ourselves that FormSignerUtils will not introduce some problem.
See https://github.com/jclouds/jclouds/pull/1102#issuecomment-302682049
for details.
This annotation is introduced as a temporary measure in order to
decouple the functionality of FormSignerUtils#getAnnotatedApiVersion
from @SinceApiVersion and the tests in question. It can be removed and
replaced by @SinceApiVersion when those tests are fixed.
Designates that a method overrides the {@link ApiVersion} on the class
with a specific value.
This is a follow-up to https://github.com/jclouds/jclouds/pull/1091
and particularly the comment at
https://github.com/jclouds/jclouds/pull/1091#issuecomment-299202429:
I have been trying this out and I think we will need to extend it for
practical purposes; if you want to create a VPC and subnet and then
deploy a machine on to it, you also need to jump through a few other
hoops apart from creating the subnet:
- modify the subnet attributes to permit auto-assign public
IP ("ModifySubnetAttribute")
- create an Internet Gateway on the VPC ("CreateInternetGateway")
- get and then modify the routing table of the subnet to add a public
(0.0.0.0/0) route through the newly added gateway ("CreateRoute" and
friends)
There are three AWS APIs needed for the above, an `InternetGatewayApi`,
a `RouteTableApi` and a method in the subnet API, I guess, for modifying
attributes on subnets. This PR contains the `InternetGatewayApi`.
Andrew Gaul
Andrea Turli
cpanato
Svetoslav Neykov
Ignasi Barrera
El del tallat
Stuart Hendren
Nelson Araujo
Geoff Macartney
Andrew Gaul
Duncan Godwin
Andrea Turli