On 1/4/13 3:51 PM, "Alex Huang" <alex.hu...@citrix.com> 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. 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 >refactoring > - 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. Will do the merge after api-refactoring merge > >--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 >
