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