These classes should not close the release the payload as they are not
reading it.
- fix swift
- fix openstack-swift v1 and v2
- fix RetryOnRenewTest for v1 and v2
When Class.forName is called for a class in a different bundle it will
fail as the default karaf class loader won't load classes from other
bundles.
I have fixed this by using the classloader of the original
(non-autovalue) type and assuming it will be in the same bundle as the
autovalue type (I think this is a reasonable assumtion).
So far the only place where I've actually seen this being an issue is
when using the jclouds-labs-google provider within karaf. It fails
when serialising the Firewall.Rule class within a FirewallOptions
object.
The defaults of maven-bundle-plugin set the required version range to
only match guava-16, but the actual usage of guava within jclouds allows
any version after guava-16.
This helps dependent projects mix jclouds with bundles using other guava
versions within OSGi environments.
Previously not all fields of RunScriptOptions were included in copyTo
(e.g. runAsRoot and initScript).
Also options.equals(options.clone()) failed if options.loginPassword
was originally null - in the cloned object, it would be Optional.absent.
Fixes RunScriptOptions.toString, to only say “loginPasswordPresent”
if optional.isPresent().
now just pick the best one. it matters only when we are going to log in to a machine.
the only time the problem has been observed has been with pre-existing machines set up
outwith jclouds with multiple password.
On SUSE, the “-f” force option is not available for groupadd,
so `groupadd -f wheel` returns exit code 9 if the group already
exists. To avoid this, first check if the group exists.
In normal usage, this doesn’t matter: the script continues with the
next command anyway.
However, if the statements generated by UserAdd or AdminAccess are
used outside of that context (e.g. by code external to jclouds), then
this can cause them to fail.
- Adding env_reset to the default configuration in /etc/sudoers
- Adding secure_path to the default configuration in /etc/sudoers
- secure_path value is
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Since commit 56e687f497, Linux line endings (LF) are enforced. But on
Windows, a common practice is to set core.autocrlf to 'auto', wich mean
that the local copy of the file has Windows line endings, whereas the
remote copy has Linux line endings (cf. https://help.github.com/articles/dealing-with-line-endings/#platform-windows).
With core.autoclrf=auto, Checkstyle will throw an error because local
files will have Windows line endings.
This setting will set Linux line endings for all text files, except
.cmd files.
Get the faultCode and faultMessage to actually be parsed (though I'm
not sure they're ever used), add statusCode, statusMessage and
statusUpdateTime, and have AWSEC2TemplateOptions default to a sane 30
minute lifetime for spot instance requests, so they don't get orphaned
forever if the price is too low etc.
deprecated hardware types in EC2 are flagged using this, according to latest AWS advice,
to fix situations where deprecated hardware types would be chosen when a non-deprecated alternative exists.
we also deprecate T2 because it requires a VPC.
also fixes semantics of ImagesToRegionAndIdMap to match the logic used in the TemplateBuilderImpl;
RegionAndName should contain the ID not the ProviderID. this is only really used in tests so no external impact.
(previously the cache only worked if provider ID matched the non-location segment of the image ID.)
however this does now assert that image id's are in the right format for AWS, as suggested by @nacx.
Andrea Turli
Duncan Grant
Ivana Yovcheva
Arvind Nadendla
Josef Cacek
Ciprian Ciubotariu
Aled Sage
Alex Heneveld
Ignasi Barrera
Graeme-Miller
Zack Shoylev
Nikolay Sokolov
Stuart Hendren
Yavor Yanchev
John McDonnell
olivierlemasle
Andrew Kennedy
Irmo Manie
Andrew Bayer
Marcus Wanner