On Nov 24, 2014, at 3:44 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote:
> “..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: https://github.com/apache/cloudstack/tree/master/awsapi 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: https://reviews.apache.org/r/21776/ 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: http://sebgoa.blogspot.de/2014/06/eutester-interesting-tool-based-on-boto.html -sebastien > > Thanks > — > Chiradeep > > From: sebgoa <run...@gmail.com<mailto:run...@gmail.com>> > Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Date: Monday, November 24, 2014 at 11:39 AM > To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Subject: Re: Moving ec2stack and gstack to the cloudstack repos. > > > On Nov 24, 2014, at 7:19 PM, Chiradeep Vittal > <chiradeep.vit...@citrix.com<mailto:chiradeep.vit...@citrix.com>> 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 > <run...@gmail.com<mailto:run...@gmail.com><mailto:run...@gmail.com>> > Reply-To: > "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>" > > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>> > Date: Saturday, November 22, 2014 at 12:41 PM > To: > "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>" > > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>> > Subject: Moving ec2stack and gstack to the cloudstack repos. > Folks, > Some of you may know of the existence of: > https://github.com/BroganD1993/ec2stack > https://github.com/NOPping/gstack > 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 > >
