End of January is just code freeze I think, still time to fix bugs. On Jan 5, 2013 3:05 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
> > > 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<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 >>> >> >>
