incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <HTrippa...@schubergphilis.com>
Subject Re: [ASF40][DISCUSS] Split AWS API / CloudBridge into a separate project
Date Fri, 12 Oct 2012 06:12:23 GMT


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.


> 
>> 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