On Oct 9, 2012, at 2:40 PM, Prasanna Santhanam wrote: > On Tue, Oct 09, 2012 at 08:14:12AM -0400, Rohit Yadav wrote: >> Hi Wido, >> >> Thanks for starting this thread. I was about to post something on this issue. >> >> On 09-Oct-2012, at 5:02 PM, Wido den Hollander <w...@widodh.nl> wrote: >> >>> Hi, >>> >>> I started a innocent thread on the -dev list yesterday[0] about some >>> packaging remarks regarding the AWS API aka CloudBridge. >>> >>> This turned out to be a rather large thread where Edison mentioned[1] we >>> might want to split this out into a separate repository. >>> >>> Some time ago we agreed that we don't want to split CloudStack up into >>> multiple smaller projects since it would be very hard to keep all the >>> projects in sync. >> >> I agree, splitting into multiple subproject will make it hard for us to keep >> up. >> But, awsapi is not actually part of the project. >> >>> >>> I'm now looking at packaging AWS API into Deb files as by CS-294[2], but >>> I'm thinking about Edison's remark. >>> >>> I know this question might come at a awkward moment, just prior to the >>> 4.0 release, but when I create a cloud-awsapi Debian package people will >>> start using it and we'll be dealing with the legacy at a later point. >> >> I agree. The awsapi servlet runs separately on port 7080 and >> communicates/forward request to CloudStack's 8080 like any other client. >> So, we can separate that out in its own repository which totally makes >> sense, as it's just a wrapper for a client. >> >>> >>> If we create a "cloudbridge" package separate from the cloud-* packages >>> we can move forward from there. >>> >>> At the old Github account[3] there is even a separate CloudBridge >>> repository, this got merged into master on May 25th of this year with >>> commit bc7dbd7d9681dc2729326ff78fb5fe586b336b25 >>> >>> Since 4.0 is not out of the door yet, do we want to keep this in the >>> cloudstack repository or split it out (again)? >> >> For 4.0, a lot of QA and bug fixes have been already done. Splitting >> out this point of time may cause further delay and unseen issues. >> >> While I agree with the idea, I suggest how about we do this after 4.0 >> release. >>> From my side, all the awsapi issues are resolved (unless QA reopens any >>> issue). >> >> I don't think we would want to change anything in the build system at this >> point of time. >> >>> >>> I've seen numerous build failures with awsapi breaking master while it's >>> not actually a part of the code base, so in this case I'm in favor of >>> breaking it out, but we should discuss this. >> >> +1 to breakout, but to breakout only after 4.0 release. > > +1 for breaking out in to a seperate deb/rpm package. > > I can't remember the rationale for merging cloudbridge into > cloudstack to begin with. Perhaps someone can provide that context. If > I remember, cloudbridge running on port 8080 would call cloudstack > also listening on port 8080. If deployed on the same machine this > would starve the threads on the single socket. By listening on 7080 > reduces the complexity. Deployment for end-users is also simplified - > install cloudstack + enable global setting - all in one machine and > ready to go. >
In my view, this is the key argument for keeping it in the same code base (ease of installation and configuraiton for users) With the previous setup you had to install cloudbridge in a different machine, which is awkward. +1 for keeping it as is. -sebastien > But await to hear from someone in the know, the reasons for merging > the project into Cloudstack in the first place. > > Decision to kick it out of the repo at this point will (I think) > save QA effort for now but also hurt existing users of this feature, > if any. > > -- > Prasanna.,
