Can those props be set in the specified config file? I found that
whirr.test.provider must be set in the command line (atypical,
especially if a prop file can also be specified). I added that to the wiki.
I've been busy with paying work; I will test it out again soon.
Paul
On 20130322 11:19 , Andrew Bayer wrote:
I haven't actually run the full suite of integration tests in a long time,
but it looks like those errors are due to identity/credential not being
set. What's your exact command line (with the keys scrubbed, of course)?
A.
On Thu, Mar 21, 2013 at 5:16 PM, Paul Baclace <[email protected]>wrote:
Andrew, thanks for sharing how you run integration tests.
In what availability zones do the integration tests work? I'm running it
from us-west-1
(I will add the answers to the wiki.)
When I run the integration tests (it also runs the unit tests each time)
from us-west-1, I get the errors (literal values sanitized):
testNoRemoteExecutionOverlap(**org.apache.whirr.actions.**integration.**PhaseExecutionBarrierTest):
POST
https://ec2.us-east-1.**amazonaws.com/<https://ec2.us-east-1.amazonaws.com/>HTTP/1.1
-> HTTP/1.1 401 Unauthorized
testFirewallAuthorizationIsIde**mpotent(org.apache.whirr.**
service.jclouds.integration.**FirewallManagerTest): POST
https://ec2.us-east-1.**amazonaws.com/<https://ec2.us-east-1.amazonaws.com/>HTTP/1.1
-> HTTP/1.1 401 Unauthorized
testUploadSmallFileToBlobCache**(org.apache.whirr.util.**integration.BlobCacheTest):
request PUT
https://7dafunky.s3.amazonaws.**com/<https://7dafunky.s3.amazonaws.com/>HTTP/1.1
failed with code 400, error: AWSError{requestId='FFFFFFFF',
requestToken='59/**blahblahblahblahblahblah', code='InvalidArgument',
message='AWS authorization header is invalid. Expected
AwsAccessKeyId:signature', context='{ArgumentValue=AWS
${sys:whirr.test.identity}:**Kblahblahblahblahblah=,
ArgumentName=Authorization, HostId=59/**blahblahblahblahblahblah}'}
Paul
On 20130320 9:06 , Andrew Bayer wrote:
I just run the integration tests directly - i.e., mvn clean verify
-Pintegration "-DargLine=-Dwhirr.test.**provider=whatever
-Dwhirr.test.identity=$**IDENTITY -Dwhirr.test.credential=$**CREDENTIAL
-Dconfig=/some/config/file.**properties" - the last bit for things like
private key, hardware id, etc, other provider-specific stuff I want to
keep
in one place when running tests.
A.
On Tue, Mar 19, 2013 at 7:42 PM, Paul Baclace <[email protected]
wrote:
Hmmm, so the answer is RTFS?
Paul
On 20130315 15:08 , Paul Baclace wrote:
I thought I would try out integration testing, and used the command from
the wiki:
mvn deploy -Ppackage -Pdeploy -Pjavadoc -DaltDeploymentRepository=id::
****
default::file:target/deploy
I thought this was for local testing, but this makes assumptions about
gpg and signing so it does nothing for me. Perhaps the wiki needs to
clarify that.
Instead, I will use:
mvn install package assembly:assembly
to build and then scp target/whirr-*-SNAPSHOT.tar.gz to my test env,
expand it, and I will try the integration tests.
Q: When running integration tests, what can I expect for machine usage
and duration?
Paul
