I wonder if this Swift-support question has gone out to the CloudStack users e-mail list for opinions?
On Wed, Jul 10, 2013 at 12:13 PM, Edison Su <edison...@citrix.com> wrote: > 1. Add swift back is just one or two days work, plus maybe one or two > days, to setup a swift environment. > 2. There is no single user from the "group of swift users" jumping into > the thread. Do they really care about this feature? > 3. If we add this feature back, will we test it for each release? Such as > adding it into automate test? Right now, I break this feature, I am pretty > sure, it will be broken by other developers, if we continue adding feature > without test. > 4. Claim a feature is supported for each release without test, is worse > than saying not supported a feature. If we want to support a feature, we > should test it for each release. If so, who will want to test this feature? > > > -----Original Message----- > > From: Caleb Call [mailto:calebc...@me.com] > > Sent: Wednesday, July 10, 2013 8:53 AM > > To: dev@cloudstack.apache.org > > Cc: Edison Su > > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in > 4.2? > > > > It's decisions like this (dropping a previously advertised supported > feature > > simply because it wasn't tested) are part of the reasons that have > changed > > our plan to use Cloudstack in our corporate environment. I'm glad to see > > Chip, David, and others pushing back on the decision to just drop it and > fix it > > in the next dot release (same story as OVM, go back and read the > discussions > > on the choice to drop it and they sound identical to what you're saying) > which > > generally means it's getting dropped for good. It doesn't matter if the > > feature currently works or not or if it's been tested in a while or not, > it's being > > advertised as being supported and people/companies make plans based on > > those supported features. Although my voice doesn't mean a lot, I too > > would vote this as a blocker. If it's going to be dropped, users need > to be > > notified well in advanced so they can be make plans moving forward > instead > > of suddenly being stranded on an out-dated version. > > > > > > On Jul 9, 2013, at 6:39 PM, Mathias Mullins <mathias.mull...@citrix.com> > > wrote: > > > > > I've been watching from the outside and tracking the entire > > > discussion, and with what has happened with the delays with 4.0 and > > > 4.1 am worried that this could be come the next delayer to the release > > > of 4.2. At the same time, I'm very much in agreement with David N., > > > Chip and John B. that we can't just drop a feature because it hasn't > > > been attiquately tested in that past releases. > > > > > > My observations - > > > 1. There is not a quick fix here. > > > 2. We don't know who can do it. > > > 3. We're not sure how to do it properly 4. Currently we can't even > > > agree on whether we go with the original version or the newer one. > > > 5. We can't validate user base immediate need and requirement for the > > > feature. > > > 6. We're stuck in Analysis paralysis! > > > > > > Conclusion - If we don't get past these in short order we are going to > > > jeopardize 4.2 timely release. > > > > > > Suggestion: > > > Based off my work with other (corporate) software releases, if we > > > can't validate the immediate need, we don't know the immediate fix, > > > and we don't have the right people to do it should we slate this for > > > 4.2.1 and lower this to a Major for 4.2? We don't delay a major > > > release, and at the same time we dedicate ourselves to not stranding a > > > user. We need to do this, but at this point we need to do it right for > that > > user base too. > > > > > > We work to fix the previous version and we work to support new > versions. > > > We get the right resources in to assist, and we make it an immediate > > > priority to address. If we can fix and test properly before the cut of > > > 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes > > > out with 4.2.1 asap. > > > > > > So there's my ramblings. How far off base am I? :-) > > > > > > Ready, setŠ fire! > > > Matt > > > > > > > > > > > > On 7/9/13 5:23 PM, "Animesh Chaturvedi" > > > <animesh.chaturv...@citrix.com> > > > wrote: > > > > > >> > > >> > > >>> -----Original Message----- > > >>> From: Chip Childers [mailto:chip.child...@sungard.com] > > >>> Sent: Tuesday, July 09, 2013 11:57 AM > > >>> To: Edison Su > > >>> Cc: <dev@cloudstack.apache.org> > > >>> Subject: Re: Swift in 4.2 is broken, anybody wants it to be > > >>> supported in 4.2? > > >>> > > >>> On Tue, Jul 09, 2013 at 06:55:03PM +0000, Edison Su wrote: > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Chip Childers [mailto:chip.child...@sungard.com] > > >>>>> Sent: Tuesday, July 09, 2013 11:22 AM > > >>>>> To: Edison Su > > >>>>> Cc: <dev@cloudstack.apache.org> > > >>>>> Subject: Re: Swift in 4.2 is broken, anybody wants it to be > > >>> supported in 4.2? > > >>>>> > > >>>>> On Tue, Jul 09, 2013 at 06:12:22PM +0000, Edison Su wrote: > > >>>>>> If it's ok to use S3 api talking to swift, then there is zero > > >>>>>> effort to support > > >>>>> Swift. > > >>>>>> But who will make the decision? > > >>>>> > > >>>>> We, as a community. It's *always* that answer. > > >>>>> > > >>>>> If you are proposing this as the corrective path, then ok... > > >>>>> let's see if others have opinions about this though. > > >>>>> > > >>>>> Heres how I see it: > > >>>>> > > >>>>> Pros - > > >>>>> * Code within the master branch has functional S3 API support > > >>>>> * We seem to have more contribution around this interface spec > > >>>>> * Having S3 as the only non-NFS secondary storage API reduces the > > >>>>> long-term support / test efforts > > >>>>> > > >>>>> Cons - > > >>>>> * We may have an expectation issue for existing users that only > > >>> have the > > >>>>> native Swift API enabled in their environment (although I'm not > > >>> aware > > >>>>> of the Swift API's stability between their releases) > > >>>> > > >>>> I think you get into the same situation as I did, without input > > >>>> from > > >>> users who is using Swift, or the company who is supporting Swift, > > >>> what we are talking about here is just hypothetic. > > >>>> If we really want to support Swift, and support it better, we need > > >>>> to > > >>> get domain expert involved in the discuss. > > >>> > > >>> Does your $dayjob happen to have a customer that might be using this > > >>> integration? If so, could your $dayjob product manager chime in on > > >>> the discussion? > > >>> > > >> [Animesh>] I followed up with $dayjob product manager, there was a > > >> customer who was interested in this integration a while back but did > > >> not end up using it. > > >>>> > > >>>>> * We haven't tested Swift as an S3 API provider yet (but could). > > >>>>> > > >>>>> Personally, if it gets tested and proven to work as well or better > > >>>>> than other > > >>>>> S3 providers, I'm +1 on this being the remediation approach. > > >>>>> > > >>>>> Others? > > >>>> > > > > > -- *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> *™*
