integration test configuration unnecessarily annoying

[Adrian Cole <ad...@jclouds.org>]

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

Re: integration test configuration unnecessarily annoying

[Tom White <to...@cloudera.com>]

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 <ad...@jclouds.org> 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

Re: integration test configuration unnecessarily annoying

[Adrian Cole <ad...@jclouds.org>]

I'll totally help sort this stuff.

-A

On Fri, Aug 3, 2012 at 3:49 PM, Andrew Bayer <an...@gmail.com> wrote:

> As Tom mentioned, it's not toooooo hard to specify the private key, but
> it's still a bit annoying.
>
> And yeah, I'm still baffled by the test properties stuff. Redoing that to
> be more like jclouds would be super sweet.
>
> A.
>
> On Thu, Aug 2, 2012 at 10:02 AM, Adrian Cole <ad...@jclouds.org> 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
> >
>

Re: integration test configuration unnecessarily annoying

[Andrew Bayer <an...@gmail.com>]

As Tom mentioned, it's not toooooo hard to specify the private key, but
it's still a bit annoying.

And yeah, I'm still baffled by the test properties stuff. Redoing that to
be more like jclouds would be super sweet.

A.

On Thu, Aug 2, 2012 at 10:02 AM, Adrian Cole <ad...@jclouds.org> 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
>