cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [ASF40][DISCUSS] Split AWS API / CloudBridge into a separate project
Date Tue, 09 Oct 2012 12:14:12 GMT
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 <> 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.

> Note: We already have a LOT of e-mail on this list, so can we try to 
> stick ontopic here and keep it to the point? Tnx!



> Wido
> [0]: 
> [1]: 
> [2]:
> [3]:

View raw message