Here is my design document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Implement+SolidFire+(storage)+plug-in+and+expose+control+of+IOPS+to+admins+and+end+users
I apologize for not understanding the process when it comes to adding plug-ins to CloudStack. Thanks for taking a look! :) On Thu, May 30, 2013 at 6:21 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > I have created the following JIRA ticket: > > https://issues.apache.org/jira/browse/CLOUDSTACK-2778 > > > On Thu, May 30, 2013 at 6:11 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Thanks, Animesh...I will take a look at the Design Documents link you >> provided. >> >> >> On Thu, May 30, 2013 at 5:55 PM, Animesh Chaturvedi < >> animesh.chaturv...@citrix.com> wrote: >> >>> Accidently sent too soon, updated my response in-line to Mike >>> >>> > -----Original Message----- >>> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >>> > Sent: Thursday, May 30, 2013 4:50 PM >>> > To: dev@cloudstack.apache.org >>> > Subject: RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >>> > > Sent: Thursday, May 30, 2013 1:20 PM >>> > > To: dev@cloudstack.apache.org >>> > > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>> > > >>> > > Hi Animesh, >>> > > >>> > > I know you and I talked about this earlier in the month, but I just >>> > > wanted to make sure we were OK with me not providing a feature >>> > > proposal for the storage plug-in work I'm doing for 4.2. >>> > > >>> > > As you may recall, I have developed a storage plug-in for SolidFire, >>> > > enhanced the storage framework, and submitted the code a couple days >>> > > ago. >>> > > >>> > > Please let me know. >>> > > >>> > > Thanks! >>> > [Animesh>] In your previous email you had asked on how to handle if you >>> > are not able to complete the implementation by freeze date and I had >>> > responded that we are on time bound release and if a logical chunk is >>> > available by freeze date that has been tested and ready, that chunk can >>> > come in. My bad I did not realize that feature proposal was not >>> > submitted for your plugin. I see your patch request >>> > https://reviews.apache.org/r/11479/ submitted on 5/28 has good >>> > description but it's not complete as per our design documents. Here is >>> > link to 4.2 Design Documents on wiki >>> > https://cwiki.apache.org/confluence/x/dzXVAQ. We follow the process >>> outlined in >>> > >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Adding+new+features+and+design+documentsfor >>> proposing new features >>> > >>> > Comments from anyone else in community, with the current 4.2 timeline >>> > the proposal date is already past due, how should we suggest we proceed >>> > on Mike's contribution? I think formal proposal and discussion needs to >>> > happen for inclusion. >>> > >>> > If we move towards extending the freeze date by 4 weeks then obviously >>> > it is not an issue. >>> > >>> > >>> > > >>> > > On Thu, May 30, 2013 at 2:11 PM, Animesh Chaturvedi < >>> > > animesh.chaturv...@citrix.com> wrote: >>> > > >>> > > > >>> > > > >>> > > > > -----Original Message----- >>> > > > > From: Wido den Hollander [mailto:w...@widodh.nl] >>> > > > > Sent: Thursday, May 30, 2013 11:42 AM >>> > > > > To: dev@cloudstack.apache.org >>> > > > > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>> > > > > >>> > > > > >>> > > > > >>> > > > > On 05/30/2013 07:43 PM, Chiradeep Vittal wrote: >>> > > > > > I'm actually OK with delaying the release (as you pointed out, >>> > > > > > 4.1 impacted 4.2 in a big way). *I* like flexibility. But it >>> > > > > > behooves the community to have a stable set of rules. >>> > > > > > >>> > > > > > It is the cognitive dissonance that bothers me. Theoretically a >>> > > > > > time-based release doesn't care about such impacts, but reality >>> > > > > > is that if someone has been working on a feature for 4 months >>> > > > > > and it doesn't make it because of the cut-off, they are going >>> to >>> > > > > > feel aggrieved, especially if at some point in the past the >>> > > > > > community >>> > > > > agreed to make an exception. >>> > > > > > >>> > > > > >>> > > > > I ack on this one. A lot of work went into the object store >>> branch >>> > > > > (since that's what discussion seems to be pointing at) and it >>> > > > > would be a nightmare for the developers to merge this into 4.3. >>> > > > > >>> > > > > John had valid points on the merge of the branch, but imho those >>> > > > > can be fixed after it's merged in. >>> > > > > >>> > > > > It's feature freeze, but it doesn't mean that we can't do any >>> > > > > squashing of bugs. >>> > > > > >>> > > > > Other developers are also waiting on merging their stuff in after >>> > > > > the freeze so it will hit 4.3 >>> > > > > >>> > > > > I wouldn't open the window for features longer since that might >>> > > > > bring more stuff into 4.2 which needs QA as well. >>> > > > > >>> > > > > Wido >>> > > > > >>> > > > [Animesh>] Like in the original schedule for 4.1 / 4.2 feature >>> > > > proposals are closed 3-4 weeks before the freeze date, we can still >>> > > > go with compromise of 4 weeks extension in feature freeze date but >>> > > > limit feature proposal to come in by June 1st week >>> > > > >>> > > > > > On 5/30/13 3:49 AM, "John Burwell" <jburw...@basho.com> wrote: >>> > > > > > >>> > > > > >> Chiradeep, >>> > > > > >> >>> > > > > >> As I understood that conversation, it was about permanently >>> > > > > >> changing the length of release cycles. I am proposing that we >>> > > > > >> acknowledge the impact of the longer than anticipated 4.1.0 >>> > > > > >> release, and push out 4.2.0. 4.3.0 would still be a four >>> month >>> > > > > >> release cycle, it would just start X weeks later. >>> > > > > >> >>> > > > > >> I like Chip's compromise of 4 weeks. I think it would be a >>> > > > > >> great benefit to the 4.2.0 release if the community had the >>> > > > > >> opportunity to completely focus on its development for some >>> > period of time. >>> > > > > >> >>> > > > > >> Finally, to David's concern that other features might be added >>> > > > > >> during such an extension. I think that would be acceptable >>> > > > > >> provided they pass review. The goal of my proposal is not >>> > > > > >> permit more features but to give the community time to review >>> > > > > >> and collaborate on changes coming into the release. If >>> > > > > >> additional high quality feature implementations happen to get >>> > > > > >> merged in during that period then I consider that a happy side >>> > effect. >>> > > > > >> >>> > > > > >> Thanks, >>> > > > > >> -John >>> > > > > >> >>> > > > > >> >>> > > > > >> On May 30, 2013, at 1:51 AM, Chiradeep Vittal >>> > > > > >> <chiradeep.vit...@citrix.com> wrote: >>> > > > > >> >>> > > > > >>> This topic was already discussed here: >>> > > > > >>> >>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235 >>> > > > > >>> .h >>> > > > > >>> tml >>> > > > > >>> >>> > > > > >>> >>> > > > > >>> The consensus then was "revisit *after* 4.2". I won't rehash >>> > > > > >>> the pros and cons, please do familiarize yourself with that >>> > thread. >>> > > > > >>> >>> > > > > >>> >>> > > > > >>> On 5/29/13 10:10 PM, "Mike Tutkowski" >>> > > > > >>> <mike.tutkow...@solidfire.com> >>> > > > > >>> wrote: >>> > > > > >>> >>> > > > > >>>> +1 Four weeks extra would be ideal in this situation. >>> > > > > >>>> >>> > > > > >>>> >>> > > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen >>> > > > > >>>> <run...@gmail.com>wrote: >>> > > > > >>>> >>> > > > > >>>>> >>> > > > > >>>>> >>> > > > > >>>>> On 30 May 2013, at 06:34, Chip Childers >>> > > > > >>>>> <chip.child...@sungard.com> >>> > > > > >>>>> wrote: >>> > > > > >>>>> >>> > > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell >>> > > > > >>>>>> <jburw...@basho.com> >>> > > > > wrote: >>> > > > > >>>>>> >>> > > > > >>>>>>> All, >>> > > > > >>>>>>> >>> > > > > >>>>>>> Since we have taken an eight (8) week delay completing >>> the >>> > > > > >>>>>>> 4.1.0 >>> > > > > >>>>> release, I would like propose that we re-evaluate the >>> > > > > >>>>> timelines for the >>> > > > > >>>>> 4.2.0 release. When the schedule was originally conceived, >>> > > > > >>>>> it was intended that the project would have eight (8) weeks >>> > > > > >>>>> to focus exclusively on >>> > > > > >>>>> 4.2.0 >>> > > > > >>>>> development. Unfortunately, this delay has created an >>> > > > > >>>>> unfortunate conflict between squashing 4.1.0 bugs and >>> > > > > >>>>> completing 4.2.0 features. I propose that we acknowledge >>> > > > > >>>>> this schedule impact, and push back the 4.2.0 feature >>> freeze >>> > > > > >>>>> date by eight (8) weeks to 2 August 2013. This delay will >>> > > > > >>>>> give the project time to properly review merges and address >>> > > > > >>>>> issues holistically, and, hopefully, relieve a good bit of >>> > > > > >>>>> the stress incurred by the simultaneous >>> > > > > >>>>> 4.1.0 and 4.2.0 activities. >>> > > > > >>>>>>> >>> > > > > >>>>>>> Thanks, >>> > > > > >>>>>>> -John >>> > > > > >>>>>> >>> > > > > >>>>>> This is a reasonable idea IMO. I'd probably only extend by >>> > > > > >>>>>> a month personally, but your logic is sound. I'd much >>> > > > > >>>>>> rather have reasoned discussions about code than argue >>> > > > > >>>>>> procedural issues about timing any day. This might help >>> > > > > >>>>>> facilitate that on some of the features folks are >>> > scrambling to complete. >>> > > > > >>>>>> >>> > > > > >>>>>> Others? >>> > > > > >>>>> >>> > > > > >>>>> I am +1 on this, 4 weeks maybe ? >>> > > > > >>>> >>> > > > > >>>> >>> > > > > >>>> >>> > > > > >>>> >>> > > > > >>>> -- >>> > > > > >>>> *Mike Tutkowski* >>> > > > > >>>> *Senior CloudStack Developer, SolidFire Inc.* >>> > > > > >>>> e: mike.tutkow...@solidfire.com >>> > > > > >>>> o: 303.746.7302 >>> > > > > >>>> Advancing the way the world uses the >>> > > > > >>>> cloud<http://solidfire.com/solution/overview/?video=play> >>> > > > > >>>> * * >>> > > > > >>> >>> > > > > > >>> > > > >>> > > >>> > > >>> > > >>> > > -- >>> > > *Mike Tutkowski* >>> > > *Senior CloudStack Developer, SolidFire Inc.* >>> > > e: mike.tutkow...@solidfire.com >>> > > o: 303.746.7302 >>> > > Advancing the way the world uses the >>> > > cloud<http://solidfire.com/solution/overview/?video=play> >>> > > *(tm)* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *™* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
