cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: [MERGE] Merge Javelin branch into master
Date Sat, 05 Jan 2013 00:15:41 GMT

On 1/4/13 3:51 PM, "Alex Huang" <> wrote:

>I propose that we use the MERGE tag for any branch merging.  I've changed
>this subject as such.
>Chip also raised some issues in another thread.  Let's try to merge them
>on to this discussion.  Please raise again if this doesn't answer your
>I like to add some things to what Kelven has talked about here.
>- Item 1 touch a great deal of of CloudStack 4.0 code but problems will
>rise very quickly and the fixes should be small.  Basically if the server
>can't come up during our test, this doesn't work.  So we will make sure
>that server is up and running the automated tests before merging.

Yes. We've mocked the same semantics on @DB and Adapters<T> injection with
Spring(these two are the only ones that affect us from a direct drop-in
for Spring), if it works in one place, it should work for all. The
equivalent functionalities will be validated by automated tests.

>- For items 2, 3, 4, we were worried about the effect extended changes
>would have on the CloudStack 4.0 code so what we've done are as follows:
>	- A new set of subdirectories:
>		- framework - for any work in ipc/jobs/event notification.
>		- engine - for any work in storage refactoring and vm orchestration
>		- services - for any services build on top of framework and engine but
>currently there are none.
>	- We have minimized changes in the CloudStack 4.0 code to appropriately
>call out to engine libraries but no in place changes to logic.  For
>example, none of the old code has been changed to use the new ipc
>	- The code changes in engine have their own unit tests.  I will let
>Edison and Prachi talk about that.  Until the unit tests have worked out,
>we do not swap out code from the CloudStack 4.0 code.
>For the merge, we will do the following:
>- Wait for the api-refactoring merge.
>- Pull in all master changes and make sure the unit tests are all running
>or have been appropriately changed to run.
>- Make sure automated testing is running against the new server.
>- Merge back into master.

Will do the merge after api-refactoring merge

>> -----Original Message-----
>> From: Kelven Yang []
>> Sent: Friday, January 04, 2013 3:13 PM
>> To:
>> Subject: [PROPOSAL] Merge Javelin branch into master
>> I'm proposing another branch merge after API-refactoring branch, to
>> javelin branch into the main stream. Javelin branch contains a number of
>> architecture refactoring efforts,
>> 1. Adopting Spring Framework for dependency injection of CloudStack
>> internal components
>> 2. IPC framework for inter component communications
>> 3. Storage subsystem refactoring
>> 4. CloudStack Orchestration Engine refactoring
>> Majorities of the new refactoring work are independent of existing
>> CloudStack components, therefore merging these independent newly
>> developed
>> components should not have a big impact to existing code base. The major
>> impact of this merge will be on #1, as it touches almost every component
>> in the existing code base, DAOs, Adapters, Managers, etc. In order to
>> seamlessly replace our existing ComponentLocator with Spring injection
>> framework. We've done following refactoring to existing code base.
>> 1) Remove all un-necessary runtime bindings to ComponentLocator at Daos,
>> Managers, Adapters, etc
>> 2) Using standard javax @Inject to replace with customized
>> 3) Using Spring AOP to support @DB semantics
>> 4) Separate component loading and initializing to avoid inter-leaving
>> dependencies between Spring bootstrap loader and CloudStack run-time
>> business logic.
>> 5) Move CloudStack bootstrap logic out of ComponentLocator to the
>> initialization process at business logic layer
>> The plan of performing such merge will be, we will first pull the latest
>> master content into javelin branch, complete the merge at javelin branch
>> and commit it into master after certain level of testing. The goal is to
>> make existing code works as before but will drop in newly add-ons of
>> refactoring work.
>> Kelven

View raw message