cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: Moving ec2stack and gstack to the cloudstack repos.
Date Wed, 26 Nov 2014 19:09:25 GMT
I’m +1 on this. I hope the original contributors and developers continue to invest energy
into maintaining it (rather than hoping that the community comes for free, just as a side-effect
of being in ACS).

From: Ian Duffy <<>>
Reply-To: "<>" <<>>
Date: Wednesday, November 26, 2014 at 4:46 AM
To: "<>" <<>>
Subject: Re: Moving ec2stack and gstack to the cloudstack repos.

I think unit tests are great for type checking and the like, but are
there any integration tests?

At the moment there aren't any, we could add some using eutester very
easily and chain it onto the current CI tasks. As Sebastien has mentioned
earlier in this thread he has already looked at doing this a little bit.

Not to sound tit-for-tat but awsapi has same issue and has much less unit

Any plans to add any?

Its not *my personal* immediate plan, but isn't that the beauty of open
source and community building? The project is open to everybody to
contribute, if you see value for integration tests to be added and wish to
do it then go ahead. Its a donation of code, not a we'll supply xyz
software to do xyz service and be the sole maintainers of it forever. If we
want things that work we need community(user and dev) support, want and

For me EC2Stack had two primary goals:

1) Make contributing easy, we wanted to produce clean(ish) code that was
easily extendable by the community so we could get some support if/when it
takes off. AWSAPI is a bit terrifying to look at, there's a large amount of
auto generated code and its a bit scary at first.

In brief to add a new API command:
    - Open, add a new API call into the actions object: e.g.
'AttachVolume': volumes.attach_volume,
- Head over to the referenced module/function and fill it out e.g.
- Done.

2) Make it portable. We didn't want the AWS compatibility layer to always
have to be hosted by the Cloudstack provider. We wanted the flexibility to
use it against any Cloudstack 4.0.0> API. This was a success and we
successfully use EC2Stack against ExoScale as shown in the earlier
referenced screencast.

Hope this answers your questions,


On 26 November 2014 at 02:47, ChunFeng <<>>

hi all,

I need help for  a clean picture about  the umbrella projects of
such as :
1. the umbrella project links in homepage
2. the source code structure and relations with cloudstack source code in
git repos.
3. the rules for us to agree one as umbrella projects

BTW,  is there any others umbrella proejcts as cloudmonkey ?



------------------ Original ------------------
From:  "Sebastien Goasguen"<<>>;
Date:  Tue, Nov 25, 2014 06:29 AM
To:  "dev"<<>>;

Subject:  Re: Moving ec2stack and gstack to the cloudstack repos.

On Nov 24, 2014, at 5:05 PM, Chiradeep Vittal <<>>

> I do see a bug fix this year from Likitha  and the fact that Hugo etc
are making fixes is positive as well.
> But, the end state we desire is (a) good AWSAPI implementation with
automated tests, not (b) 2 AWSAPI implementations with no tests!

time for bed here, but to keep the conversation going, couple things:

Hugo is fixing coverity issues kind of automatically, I don't think it
represents a need.
One fix from Likitha and one applied patch from me in a year is really

We don't test the current awsapi during the release process or upgrade, so
I actually have no clue if it's working with 4.3 and 4.4.

Right now I don't see tests for the current awsapi, at least not on
Current awsapi also includes S3 stuff which I think we can all agree is
confusing and unused since it's really an interface to an NFS store and not
a distributed object store.

So the choice for me is between:

-current awsapi, not clearly maintained, without tests and which state in
the release is unknown


-a new implementation < 6 months old, smaller code base, up to date with
AWS version number, tested manually with boto, eutester and awscli and with
99% unit test coverage.

> —
> Chiradeep
> From: Sebastien Goasguen <<><>>
> Reply-To: "<><>"
> Date: Monday, November 24, 2014 at 1:36 PM
> To: "<><>"
> Subject: Re: Moving ec2stack and gstack to the cloudstack repos.
> On Nov 24, 2014, at 3:44 PM, Chiradeep Vittal <<><>>
> “..nobody in the community (aside from you, Likitha and Prachi) have
actually touched that code in the last two years. So if we don't maintain
that code.."
> That’s false equivalence. Clearly it has been maintained since there are
bug fixes.
> I don't know…I look at:
> I see Hugo has fixed some coverity issues
> I applied a review 8 months ago
> the rest is older. but maybe I am not looking at this the right way.
> there is one review still pending:
> So from looking at it this way it does not look actively maintained. No ?
> But we’re looking to make things better. I am not sure HOW bringing in
another compatibility layer brings benefits, UNLESS WE propose to commit
time to provide a suite of integration tests (say, via eutester)
> Do we have a suite of integration tests for awsapi that is running right
now ? where ?
> I did play with eutester and actually patched it to work with cloudstack
when I worked on ec2stack:
> -sebastien
> Thanks
> —
> Chiradeep
> From: sebgoa <<><><mailto:<>>>
> Reply-To: "<><
><>" <<><mailto:<>><>>
> Date: Monday, November 24, 2014 at 11:39 AM
> To: "<><><mailto:<>>" <<><mailto:<>><>>
> Subject: Re: Moving ec2stack and gstack to the cloudstack repos.
> On Nov 24, 2014, at 7:19 PM, Chiradeep Vittal <<><><mailto:<>>> wrote:
> Seems legit, but from (bitter) experience, there is no point in a
compatible API layer unless somebody puts in the elbow grease to test the
compatibility. Since the actual EC2 API as implemented by AWS changes
frequently and has undocumented semantics and  behavior that varies from
the WSDL, this takes some work. So, my question would be how would this
benefit the community (unless someone has tested out the compatibility with
various tools such as boto, ec2-* CLI).
> I think the main issue is the on-going maintenance of such an interface.
That's also one of the main reason why I advocate to remove awsapi, nobody
in the community (aside from you, Likitha and Prachi) have actually touched
that code in the last two years. So if we don't maintain that code and
indeed run CI against this interface, advertising that we have it gives a
false "hope" to users.
> On the other side of the coin, I think most cloud tools out there now
have native cloudstack API support (vagrant, cfg mgmt , libcloud etc…), so
the need for a pure ec2 interface has diminished greatly.
> -sebastien
> From: Sebastien Goasguen <<><
> Reply-To: "<><
><><>" <<><><mailto:<>><>>
> Date: Saturday, November 22, 2014 at 12:41 PM
> To: "<><><mailto:<>><>"
> Subject: Moving ec2stack and gstack to the cloudstack repos.
> Folks,
> Some of you may know of the existence of:
> These represent a EC2 and a GCE interface to cloudstack.
> Flask applications that map the requests to the cloudstack API.
> There was only 3 contributors, myself, Ian (PMC and committer on CS) and
Darren Brogan.
> Darren worked on this during his GSoC 2014 summer project.
> Both projects are on Apache V2 license.
> The three of us (Ian, Darren and myself) agree that we would like to
move them under the umbrella of cloudstack and manage separate releases
like we do cloud monkey.
> Any objections ?
> -Sebastien

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