incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [MERGE] Merge Javelin branch into master
Date Sat, 05 Jan 2013 16:18:33 GMT
End of January is just code freeze I think, still time to fix bugs.
On Jan 5, 2013 3:05 AM, "Wido den Hollander" <wido@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.yang@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
>>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message