Thanks John for summary. From QA stand point it would make sense to merge once

- assigned test cases are executed and pass rate is on par with release 
criteria  ( test plans published and execution results are being posted)
- automation runs are successful and shows same pass rate as Master
- blockers are fixed before merge

Let me know if this would be agreeable. QA usually would not test features 
completely on feature branches but this one is exception given the nature of 
changes. 

Thanks
/sudha

-----Original Message-----
From: John Burwell [mailto:jburw...@basho.com] 
Sent: Thursday, June 13, 2013 9:38 AM
To: dev@cloudstack.apache.org
Subject: Object_Store storage refactor Meeting Notes

All,

Edison Su, Min Chen, Animesh Chaturvedi, and myself met via teleconference on 
11 June 2013 @ 1:30 PM EDT.  The goal of the meeting was determine the path 
forward for merging the object_store branch by the 4.2 freeze date, 30 June 
2013.  The conversation focused on the following topics:

        * Staging area mechanism
        * Removing dependencies from the Storage to the Hypervisor layer
        * Dependencies of other patches on object_store
        * QA's desire to start testing the patch ASAP

Min, Edison, and I agreed that the staging mechanism must age out files and use 
a reference count to ensure that file in-use are not prematurely purged.  While 
we agree that some form of reservation system is required, Edison is concerned 
that it will be too conservative and create bottlenecks.  

As we delved deeper into the subject of the storage to hypervisor dependencies 
and the reservation mechanism, we determined that NFS storage would still need 
to be the size of the secondary storage data set.  Since the hypervisor layer 
has not been completely fitted to the new storage layer, NFS would be still 
required for a number of operations.  Based on this realization, we decided to 
de-scope the staging mechanism, and leave the 4.2 object store functionality 
the same as 4.1.  Therefore, NFS will remain the secondary storage of record, 
and object storage will serve as backup/multi-zone sync.  In 4.3, we will fit 
the hypervisor layer for the new storage layer which will allow object stores 
to server as secondary storage.  This work will include removing the storage to 
hypervisor dependencies.  For 4.2, Edison and Min have implemented the critical 
foundation necessary to establish our next generation storage layer.  There 
simply was not enough time in this development cycle to make these changes and 
fit the hypervisor layer.

Due to the size of the patch, Animesh voiced QA's concerned regarding test 
scope and impact.  As such, we want to get the merge completed as soon as 
possible to allow testing to begin.  We discussed breaking up the patch, but we 
could not devise a reasonable set of chunks there were both isolated and 
significantly testable.  Therefore, the patch can only be delivered in its 
current state.  We also walked through potential dependencies between the 
storage framework changes and the solidfire branch.  It was determined that 
these two merges could occur independently.

Finally, Animesh is going to setup a meeting at Citrix's Santa Clara office on 
26 June 2013 (the day after Collab ends) to discuss the path forward for 4.3 
and work through a high-level design/approach to fitting the hypervisor layer 
to exploit the new storage capabilities.  Details will be published to the dev 
mailing list.

Thanks,
-John

On Jun 11, 2013, at 2:08 AM, Min Chen <min.c...@citrix.com> wrote:

> It is 11th June. John is not free between 9:15am to 10am, that is why 
> we schedule it at 10:30am.
> 
> Thanks
> -min
> 
> On 6/10/13 10:52 PM, "Nitin Mehta" <nitin.me...@citrix.com> wrote:
> 
>> Hi Min,
>> When you say tomorrow, what date is it 11th June or 12th ? Can the 
>> time be preponed by an hour please - its too late here ?
>> 
>> Thanks,
>> -Nitin
>> 
>> On 11/06/13 11:06 AM, "Min Chen" <min.c...@citrix.com> wrote:
>> 
>>> Hi there,
>>> 
>>> To reach consensus on some remaining NFS cache issues on 
>>> object_store storage refactor work in a more effective manner, John, 
>>> Edison and I have scheduled a GoToMeeting tomorrow to discuss them 
>>> over the phone, any interested parties are welcome to join and 
>>> brainstorm. Here are detailed GTM information:
>>> 
>>> Meeting Time: 10:30 AM  12:30 PM PST
>>> 
>>> Meeting Details:
>>> 
>>> 1.  Please join my meeting.
>>> https://www1.gotomeeting.com/join/188620897
>>> 
>>> 2.  Use your microphone and speakers (VoIP) - a headset is recommended.
>>> Or, call in using your telephone.
>>> 
>>> United States: +1 (626) 521-0017
>>> United States (toll-free): 1 877 309 2070
>>> 
>>> Access Code: 188-620-897
>>> Audio PIN: Shown after joining the meeting
>>> 
>>> Meeting ID: 188-620-897
>>> 
>>> GoToMeeting(r)
>>> Online Meetings Made Easy(r)
>>> 
>>> Not at your computer? Click the link to join this meeting from your 
>>> iPhone(r), iPad(r) or Android(r) device via the GoToMeeting app.
>>> 
>>> Thanks
>>> -min
>> 
> 

Reply via email to