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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >
