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