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? > >>>> > >
