- 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
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
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
- Fix DataDisk.CachingTypes.fromValue to recognize values properly
- Fix tests which had blob disks and managed disks at the same time
- At this point managed disks are used by default and should be tested.
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`.
- add CreateSshKeysThenCreateNodes strategy
- add PacketComputeServiceLiveTest
- add PacketTemplateBuilderLiveTest
- refactor deviceApi.actions into separate operations
- fix Device.State
- remove overriden live test as it is now pushed up to jclouds/jclouds
- improve comments on the adapter
- add DeviceApi with Mock and Live Test
- add FacilityApi with Mock and Live Test
- add OperatingSystemApi with Mock and Live Test
- add SshKeyApi with Mock and Live Test
- fix Device domain object
- refactor deviceApi.create and sshKeyApi.create as they actually return an object instead of a URI now
- add mock and live tests for device api actions
When making a GetBucketLocation request, Amazon may route the request
to the bucket region. When making it with v4 signer, the request may
fail because of the region mismatch. Concretely, a request to
test.s3.amazonaws.com may resolve to s3-us-west-2-w.amazonaws.com. The
request itself is prepared for the us-east-1 region (s3.amazonaws.com
endpoint), but then fails when the DNS resolution points to a
us-west-2 endpoint.
Bucket-in-path works around this for the GetBucketLocation requests.
That means that every GetBucketLocation request will be of the form:
https://s3.amazonaws.com/{bucket}?location. This ensures that jclouds
requests will not be subjected to Amazon's routing/DNS pointers.
Fixes: JCLOUDS-1213
- add skeleton for PacketApi with ProjectApi only
- add XAuthTokenToRequest filter
- add HttpApiModule and ParserModule
- add ProjectApi feature with Mock and Live Tests
- add pagination to Project API
- add test pagination
Jclouds sends default user agent string with each request to cloud
services. But some of the application would like to overide this and
send custom user agent instead.
This commit define a string property to overide this default user agent
string. This property will be applied to all outgoing http request to
cloud services
JCLOUDS-819
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
* Simplified ImageExtension
* Fixed access to deployed VMS
* Made api-version configurable for all apis"
* Fixed all feature live tests
* Fixed the AzureComputeServiceLiveTest
* Fixed the AzureTemplateBuilderLiveTest
* Fixed the AzureComputeImageExtensionLiveTest
The default network of recently created projects have a null value for rangeIPv4
And all regions as subnets, which do have values for the rangeIPv4.
Fixes JCLOUDS-1158
- change location scope to ZONE vs REGION
- edit the README
- fix Region.byName
- add more Regions in Region class
- address initial comments from @nacx
- revert ZONES to REGIONS
- add parser module
- remove parser from HttpApiModule
- use one region in AzureLiveTestUtils
* dynamically call TypeToken.isSupertypeOf with Guava 19 and later and
TypeToken.isAssignableFrom with Guava 18 and earlier
* consume or ignore values from methods with CheckReturnValue
* replace usage of removed Iterators.emptyIterator
This is a combination of 16 commits:
* First approach to ArbitraryCpuRamTemplateBuilderImpl
* Several fixes: refactoring some names, format, identation problems, some missing license headers and generateId method
* Refactored parse utility
* Added GoogleComputeEngineArbitraryCpuRamTemplateBuilderImpl to support GCE custom machine URI
* extracted hardware creation to automaticHardwareForCpuAndRam method
* Fixed ide automatic asterisk imports
* correcting WIP base case PR according to comments
* added machineTypeUriToHardware to set custom hardware in nodes
* fix checkstyle violations and other PR comments
* Set the providerId to custom machineType URI and fix adding node log
* Arbitrary hardware tests added to BaseTemplateBuilderLiveTest and GoogleComputeEngineTemplateBuilderLiveTest
* Added two more tests to BaseTemplateBuilderLiveTest
* Move repeated constants to TestUtils to reuse code
* Fix full path in the Hardware id and URI
* Add custom hardware tests to BaseComputeServiceLiveTest and GCEServiceLiveTest
* Change customHardware test to use buildTemplate and fix identation
Previously jclouds allocated the initial container pool as
$USERNAME-blobstore-1, 2, etc. and subsequent containers with
$USERNAME-blobstore-$RANDOM. Use only the former instead.
When writing the ~/.ssh/authorized_keys file in a script that is being
run as sudo, the file is created with the root owner, instead of the
user defined by the node credentials. File ownership should be enforced
to make sure the right owner is alwaays set.