cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [MERGE][ACS41] javelin to master
Date Mon, 28 Jan 2013 15:17:40 GMT

I echo Marcus' concerns regarding the timing of such a "high touch" change landing in master.
 We are two days before code freeze.  What 4.1.0 features/capabilities are gained by merging
javelin?  Can someone speak to the regression test strategy that has been employed to verify
the stability of the changes?

I proposed 2pm today (28 Jan 2013) [1] to meet on #cloudstack-meeting to continue our storage
design conversation.


On Jan 27, 2013, at 8:21 PM, Kelven Yang <> wrote:

> I put a wiki article about this at,
> dStack
> It explains some of the motivations for trying Spring in javelin together
> with the architecture cleanup work, as Alex has pointed, it does not
> change the business logic behind, the effort of the work is to lay out a
> more open foundation for future CloudStack evolution.
> Kelven
> On 1/26/13 9:52 AM, "Alex Huang" <> wrote:
>>> Do you have consensus on the storage piece?
>>> I didn't walk away from the storage meeting with the impression that
>>> consensus had been achieved, and there's another meeting on it next
>>> week...
>> We did not reach yet because John had something to take care of.  We
>> agreed to hold another meeting.  In principle, I think John's ideas and
>> the new storage engine are not far apart.  We're going to go into
>> specific design on the next meeting to verify that.
>> That is what I'm trying to point out here.  We should look at javelin as
>> the piece that just brings Spring support.  It's high touch but minimal
>> effect on business logic.  We can reach consensus on whether to bring in
>> the storage hookup piece when Edison ask to merge that branch in.
>> --Alex

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