cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Re: [ASF40][DISCUSS] Split AWS API / CloudBridge into a separate project
Date Fri, 12 Oct 2012 06:20:17 GMT

On 12-Oct-2012, at 11:42 AM, Hugo Trippaers <HTrippaers@schubergphilis.com> wrote:

> 
> 
> Op 9 okt. 2012 om 23:11 heeft "Wido den Hollander" <wido@widodh.nl> het volgende
geschreven:
> 
>> 
>> 
>> On 10/09/2012 07:48 PM, Chip Childers wrote:
>>> On Tue, Oct 9, 2012 at 12:31 PM, David Nalley <david@gnsa.us> wrote:
>>>> On Tue, Oct 9, 2012 at 12:17 PM, Chip Childers
>>>> <chip.childers@sungard.com> wrote:
>>>>> OK,
>>>>> 
>>>>> So let me try to summarize the opinions here:
>>>>> 
>>>>> We have a couple of folks that think it should be split back out, but
>>>>> more are erring on the side of keeping the functionality.
>>>>> 
>>>>> Assuming that we keep the code in the ACS repo for now, the second
>>>>> question is one of packaging.  Wido proposed a "cloudbridge" package
>>>>> for this specific code.  I think that makes sense, in that it gives us
>>>>> options for breaking apart from CS in the future.
>>>>> 
>>>>> Can we get some opinions about the packaging specific portion of the
issue now?
>>>> 
>>>> 
>>>> So we release source code - so from a release perspective I think it
>>>> makes next to no difference.
>>>> For the convenience binaries that are being built it might make a
>>>> tremendous amount of difference - up to an including functionality not
>>>> working
>>>> I'd specifically not want to substantially change RPMs at this stage.
>>>> Debs could have this broken out since it has never been there, but it
>>>> would all need to be tested.
>>>> 
>>>> --David
>>>> 
>>> 
>>> OK, so let's move forward with this plan:
>>> 
>>> 1 - Get the DEB package built (as a separate package).
>> 
>> This will be hard. Since we have a central control file for the Debian packaging
it will be something like cloud-awsapi or cloud-bridge
>> 
>> In the spec file I saw that that cloud-awsapi is depending on cloud-deps, so that
starts to tie it in with the rest of the code-base on a packaging level.
> 
> With the maven build a lot of the dependency problems can be fixed per sub-package. In
fact lot of fixes in there already to make sure awsapi build properly regardless of changes
to other parts of the code. 
> 
> As for packaging, the maven build is producing war files with all the deps included.
So there will be a dedicated set of dependencies for awsapi and another set for management
server etc. for packagers that should make it easy to package each item separately with its
dependencies. Most webapp class loaders will look in its Web-inf/lib dir first before going
to other places preventing conflicts with different versions of libraries.
> 
> This doesn't yet help us for 4.0, but the problem should just go away (just like the
deps directory) when people work on master again
> 
> So -1 to split it off, makes more sense to keep it in the tree for me.

-1 to split it off;
Reverting my vote due to recent changes and my better understanding of maven build system
on master.

> 
> 
>> 
>>> 2 - Test the AWS API via a DEB package installation
>>> 
>>> We don't touch the RPM's now, since it's already been tested and (as
>>> of this morning) validated as working.
>>> 
>>> Does someone want to pick up the DEB packaging for Wido (since I
>>> assume he's sleeping right now)?
>>> 
>> 
>> Not a sleep yet :) I'll be offline soon though, but I can follow up on work done
over night (for me) and continue in the morning on what Edison came up with.
>> 
>> Wido
>> 
>>> -chip
>>> 


Mime
View raw message