> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, June 13, 2013 10:43 AM > To: dev@cloudstack.apache.org > Subject: Re: Object_Store storage refactor Meeting Notes > > 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. > > -chip [Animesh>] Chip I think by now everyone knows that all decisions need to happen on the list. John B's proposal to have a face-face meeting I think is good to bring in a good proposal which can be discussed and decided on the mailing list.
> > 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
