cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: [MERGE] Merge Javelin branch into master
Date Sat, 05 Jan 2013 10:04:54 GMT


On 01/05/2013 12:51 AM, 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 questions.
>
> 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.
> - 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 refactoring

My concern is with the current CLVM and RBD code. This has to be 
(partially) re-written for the Javelin branch.

I don't want it to become blockers for the 4.1 release, but I'm not sure 
if I'll have sufficient time to re-implement that code and make sure it 
all works properly for the end of January (when the RC should come out, 
right?)

Wido

> 		- 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 mechanism.
> 	- 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.
>
> --Alex
>
>> -----Original Message-----
>> From: Kelven Yang [mailto:kelven.yang@citrix.com]
>> Sent: Friday, January 04, 2013 3:13 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: [PROPOSAL] Merge Javelin branch into master
>>
>> I'm proposing another branch merge after API-refactoring branch, to merge
>> 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
>> com.cloud.utils.component.Inject
>> 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
>

Mime
View raw message