Hi Adrian,
Agreed on both points. BTW when running integration tests I use a
small bash function:
whirr-test ()
{
mvn verify -Pintegration -DargLine="-Dwhirr.test.provider=aws-ec2
-Dwhirr.test.identity=$AWS_ACCESS_KEY_ID
-Dwhirr.test.credential=$AWS_SECRET_ACCESS_KEY
-Dconfig=.whirr-test.properties"
}
Then in ~/.whirr-test.properties I define whirr.private-key-file and
whirr.public-key-file. But I agree that making that the default for
tests would be much better!
Can you open JIRAs for these and we can get them fixed?
Thanks,
Tom
On Wed, Aug 1, 2012 at 9:02 PM, Adrian Cole <[email protected]> wrote:
> Hi, team.
>
> There's 2 gripes I have about testing whirr, one of which a very long-term
> gripe. Whirr has a lot of quality issues and we need to make it very easy
> for folks to participate and sort them out. A big piece of this is how we
> address integration testing.
>
> 1. whirr defaults to put a random ssh key on the host, which makes busy
> work for those attempting to troubleshoot issues, as they hunt the key down
> etc.
> * I understand folks who want super secure things, but that should be
> an option, not the default.
> 2. getting a sensible set of parameters to integration tests are too hard.
> TemplateBuilderStrategy hard codes values that are senseless in private
> clouds, and normal system properties are not capable of overriding tests.
> This makes more busy work, as annoying if not more than point 1.
> * We should rip out TemplateBuilderStrategy completely as it needs to die.
> * We should switch our test classes to take into account system
> properties under some prefix
>
> I would help more, if the process of testing wasn't as annoying as it is
> now.
>
> -A
