cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: Discuss EC2/S3 Test Framework for CloudStack
Date Wed, 13 Jun 2012 22:40:52 GMT
Boto is a cool python library that focuses on AWS specifically.  Sounds
like folks already built something so maybe let them have their fun? :)

When you want something for the JVM, happy to help with a jclouds option.
Seems straightforward to choose JVM tooling as you can integrate them
directly in the CloudBridge tests, also written in java.  Anyways, to each
their own.

Like I mentioned before, jclouds already has code to deal with and test EC2
dialects like Eucalyptus.  Moreover, we are currently finding compatibility
issues with CloudBridge.  We will likely end up with a separate cloudbridge
dialect osgi package/jar like we do for euca and nova.

Will keep you posted on that end.
On Jun 13, 2012 6:27 PM, "Sam Robertson" <> wrote:

> Thanks David!
> On 6/13/12 2:55 PM, "David Nalley" <> wrote:
> >On Wed, Jun 13, 2012 at 5:48 PM, Sam Robertson <>
> >wrote:
> >> I know this has come up some in recent weeks on this list and even in
> >>discussion locally.  We are trying to extend CloudStack's existing
> >>Python Testing Framework
> >>( to test
> >>the new EC2 and S3 api's recently added
> >>(
> >>and
> >>
> >> As an initial cut, we are exploring using boto
> >>( and it's corresponding
> >>test suite as a foundation
> >>( for our own test
> >>scripts.
> >
> >Interesting - what about boto is more appealing than eutester or jclouds?
> Eutester appears to be a 'beginning' but not as far along as the boto test
> suite.  It also uses boto, however it might be the better solution for
> testing since it's purpose is a test suite, but still doesn't solve our
> SOAP problem.
> >
> >>
> >> Boto does not support SOAP api and we need to test both REST and SOAP
> >>api's in CloudStack.  My current thinking is to use the AWS tools
> >>provided by Amazon (
> >>and call them directly from our test scripts, which will satisfy our
> >>SOAP requirement, but then we have two test scripts, one that uses boto
> >>and one that uses SOAP, which will get messy/complex.
> >
> >The AWS tools have several problems in my mind.
> >1. They aren't open source
> >2. Even more troubling their license actually actively limits you to
> >only using it for/with Amazon's service offering.
> >
> >Could we use euca2ools in it's place?
> Euca2ools sits on top of boto, but again might be a better approach
> overall.
> The licensing issue with the AWS tools is a big problem.  Most customers
> that use CloudBridge and the EC2 support in CloudStack use the AWS tools
> and are violating the license of those tools.  One could argue that we
> shouldn't even expose the SOAP API.
> In general, boto appears to be the magic sauce that most tools are being
> built on top of, besides amazon's own tools.
> >
> >--David
> Sam

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message