cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: Object_Store storage refactor Meeting Notes
Date Thu, 13 Jun 2013 17:42:31 GMT
First, thanks for bringing this back to the list. I'm +1 on the technical approach.

A couple of thoughts though, just so that we make sure that we keep
operating in the right manner as an Apache project:

Let's be careful about declaring something a "decision" or that
something was "determined" when it happened off-list.  I think that, 
in the case below, you were really saying "we agreed to make this the 
proposal to the list", so no harm there.

The last bit, about a meeting in person, is a little concerning to me
though...  It really needs to be open to anyone that might want to
participate if at all possible (and this means folks that aren't
physically there).  Also, please be sure to bring back a summary of the
discussions to the list, so that those not there have an opportunity to
see what was discussed (and comment if they have comments).  Think of
the outcome of the discussions as "proposals" that will be brought back 
to the list.

Sorry for sounding preachy, but it's important to keep remembering that
the list is where decisions are made...  and discussions shouldn't be
closed to community members that may have geographic or temporal constraints.


On Thu, Jun 13, 2013 at 12:38:16PM -0400, John Burwell wrote:
> 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

View raw message