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.y...@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
