The integration test is still not working for me in us-west-1.
I pushed the changes for WHIRR-693 to [email protected]:tralfamadude/whirr.git
but they have not undergone integration testing.
Paul
On 20130329 16:26 , Andrew Bayer wrote:
I believe they can be, yeah.
btw, how's your progress on https://issues.apache.org/jira/browse/WHIRR-693?
A.
On Fri, Mar 29, 2013 at 3:44 PM, Paul Baclace <[email protected]>wrote:
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.**amazon**aws.com/ <http://amazonaws.com/><
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.**amazon**aws.com/ <http://amazonaws.com/><
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/ <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
