OK, then please share your test results on the Query API side, and we can take a look. We've got two weeks to get it in good shape -- sounds like plenty to me!
Ewan. > -----Original Message----- > From: fernc...@gmail.com [mailto:fernc...@gmail.com] On Behalf Of > Adrian Cole > Sent: Thursday, August 02, 2012 12:54 PM > To: cloudstack-dev@incubator.apache.org > Cc: Prachi Damle > Subject: RE: ec2 API compatibility (WSDL vs Query) > > Right, so here's the opportunity! > > Clear out 50 bugs and a legacy of code to support, and replace them > with > the bugs in Query which we would have to address anyway. > > I understand there's a time pressure, just that I'd personally rather > not > release cloudbridge in v4.0 at all vs establish a SOAP legacy to > maintain. > > -A > On Aug 2, 2012 12:36 PM, "Sudha Ponnaganti" > <sudha.ponnaga...@citrix.com> > wrote: > > > Hi, > > > > EC2 SOAP API testing has been done. > > Here are test results : > > http://wiki.cloudstack.org/display/QA/EC2+API+support+- > +Test+Execution > > > > Two test cycles are done. Second cycle is done to cover failed and > blocked > > test cases from first run > > Total test cases run 250+ > > Total Passed 200 + > > > > Defects can be found in JIRA > > > > Thanks > > /Sudha > > > > > > -----Original Message----- > > From: Ewan Mellor [mailto:ewan.mel...@eu.citrix.com] > > Sent: Thursday, August 02, 2012 10:57 AM > > To: cloudstack-dev@incubator.apache.org > > Cc: Prachi Damle > > Subject: RE: ec2 API compatibility (WSDL vs Query) > > > > The only metric that we have (to my knowledge) is that the Query API > was > > broken for a long time (a problem with the signature-checking code, > so > > nothing worked at all). So the SOAP API is the one that's had all > the love > > from us. If you have test results, then that's far better. > > > > Ewan. > > > > > -----Original Message----- > > > From: fernc...@gmail.com [mailto:fernc...@gmail.com] On Behalf Of > > > Adrian Cole > > > Sent: 02 August 2012 10:29 > > > To: cloudstack-dev@incubator.apache.org > > > Cc: Prachi Damle > > > Subject: Re: ec2 API compatibility (WSDL vs Query) > > > > > > Do we have metrics for the relative strength of the SOAP API? Ex. > > > Integration or unit test coverage reports and suites? > > > > > > Besides shipping the wrong feature, I take issue with subjective > > > quality assessments. Hopefully, you can dispell that with a test > > > suite I can run to show objectively the quality of the SOAP API. > > > > > > I can automatically test the Query API right now, and in fact in > > > jclouds we are already doing this for greenqloud. There are a > couple > > > glitches, but nothing that cannot be sorted. > > > > > > -A > > > On Aug 2, 2012 10:12 AM, "Chip Childers" > <chip.child...@sungard.com> > > > wrote: > > > > > > > Ewan, > > > > > > > > First, thanks for stepping up to help organize everyone around > the > > > > release process. We have all agreed that getting to a "legal" > > > > release is the priority, and we also agreed to target a time- > bound > > > > release model. It's a thank-less job sometimes to be the one to > > > > "crack the wip". It was needed. Perhaps we need to look at how > to > > > > rotate that around the community for future releases, so that > > > > everybody gets a chance to take some of that heat... ;-) > > > > > > > > On the tactical topic of the AWS API's for our first release, I > > > > think we need to compromise a bit here. If Prachi can get > > > > everything working without the WSDL files being in the source > tree, > > > > then that would be sufficient to achieve our primary objective > for the > > release. > > > > Due to the noted concerns about the current quality of the query > > > > API, my personal opinion would be to release with the SOAP API > > > > intact. If we run into issues making it work without the WSDL's, > > > > we'll need an alternative strategy to deal with the licensing / > > > > copyright issue for those files. > > > > > > > > Strategically, I would like to second Chiradeep's proposal that > we > > > > aim to convert from SOAP to Query. That will require testing > > > > effort, but I believe it's the right move long term. Assuming > the > > > > WSDL's can be removed cleanly, this deprecation step would be in > a > > future release. > > > > However, I would strongly suggest that we include a notice in the > > > > 4.0 release notes that expresses our aim to convert from SOAP to > Query. > > > > This, of course, assumes that nobody strongly disagrees with that > > > > strategy. > > > > > > > > To summarize, can we agree on the following? > > > > > > > > 1 - Prachi will update the list with his findings (attempting to > > > > remove the WSDL files). > > > > 2 - If Prachi is able to get it working, we release WITH the SOAP > > > > API intact, but with a notice of planned deprecation. > > > > 3 - If Prachi is not able to get it working, then we remove the > SOAP > > > > API for this release, and do some of the basic testing required > to > > > > assess quality for the Query API. This would allow us to make an > > > > informed decision about how to handle the situation. > > > > > > > > -chip > > > > > > > > On Thu, Aug 2, 2012 at 12:41 PM, Ewan Mellor > > > > <ewan.mel...@eu.citrix.com> > > > > wrote: > > > > > No, it's not my decision to make alone. This group has asked > for > > > > time-based releases, so that's what I'm doing. If people decide > > > > that they don't want time-based releases after all, then we can > > > > start again with a new release plan. > > > > > > > > > > That's not what people have asked for though. We've asked the > > > > > question > > > > multiple times, and every time the answer comes back -- ship as > soon > > > > as you can. We haven't shipped an Apache release for four months > > > > (it will be five months on the current release plan) and we're > > > > already seeing articles saying that you shouldn't use Apache > > > > releases because they are crippled compared with Citrix's. > > > > > > > > > > Like I say, this isn't my decision. I'm just cracking the whip > to > > > > > make > > > > sure people actually get what they're asking for. If the group > > > > decides that it wants to slip to October or beyond, then that's a > > > > decision that's open to them. > > > > > > > > > > Ewan. > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: fernc...@gmail.com [mailto:fernc...@gmail.com] On Behalf > > > Of > > > > >> Adrian Cole > > > > >> Sent: 02 August 2012 09:14 > > > > >> To: cloudstack-dev@incubator.apache.org > > > > >> Cc: Prachi Damle > > > > >> Subject: Re: ec2 API compatibility (WSDL vs Query) > > > > >> > > > > >> Well, if this is your decision to make alone, then I guess > we'll > > > > >> have > > > > to either > > > > >> convince you or deal with your decision. > > > > >> > > > > >> -A > > > > >> > > > > >> On Thu, Aug 2, 2012 at 9:06 AM, Ewan Mellor > > > > >> <ewan.mel...@eu.citrix.com>wrote: > > > > >> > > > > >> > The problem is that "not well tested" is likely to be code > for > > > > >> > "doesn't work and has never worked". If someone can > convince > > > > >> > me that it will be working in the next 2 weeks (1 week of > open > > > > >> > development, 1 week stability and bugfixing) then I'm happy > to > > > > >> > take that step and remove the SOAP API and declare 4.0 to be > > > > >> > Query API only. If it can't be done in the next two weeks > then > > > > >> > we're talking about slipping the > > > > >> release, and no-one wants that. > > > > >> > > > > > >> > Ewan. > > > > >> > > > > > >> > > -----Original Message----- > > > > >> > > From: Chip Childers [mailto:chip.child...@sungard.com] > > > > >> > > Sent: 02 August 2012 08:37 > > > > >> > > To: cloudstack-dev@incubator.apache.org > > > > >> > > Cc: Prachi Damle > > > > >> > > Subject: Re: ec2 API compatibility (WSDL vs Query) > > > > >> > > > > > > >> > > From Chiradeep's note: > > > > >> > > > > > > >> > > > Currently the EC2 API layer implements both the WSDL > > > > >> > > > interface as well as the Query API. > > > > >> > > > However the Query API is not well tested. > > > > >> > > > > > > >> > > So removing the SOAP interface would leave us with the > query > > API... > > > > >> > > which would then need testing. > > > > >> > > > > > > >> > > Am I misunderstanding? > > > > >> > > > > > > >> > > -chip > > > > >> > > > > > > >> > > On Thu, Aug 2, 2012 at 11:33 AM, Ewan Mellor > > > > >> > > <ewan.mel...@eu.citrix.com> > > > > >> > > wrote: > > > > >> > > >> -----Original Message----- > > > > >> > > >> From: Chip Childers [mailto:chip.child...@sungard.com] > > > > >> > > >> Sent: 02 August 2012 07:58 > > > > >> > > >> To: cloudstack-dev@incubator.apache.org > > > > >> > > >> Subject: Re: ec2 API compatibility (WSDL vs Query) > > > > >> > > >> > > > > >> > > >> On Thu, Aug 2, 2012 at 10:56 AM, Adrian Cole > > > > >> > > >> <adrian.f.c...@gmail.com> > > > > >> > > >> wrote: > > > > >> > > >> > Just curious. > > > > >> > > >> > > > > > >> > > >> > If this is the first apache release, and cloudbridge > was > > > > >> > > >> > formerly in a different repo, why don't we just rip > out > > > > >> > > >> > the > > > > SOAP > > > > >> interface? > > > > >> > > >> > That's a heck of a lot simpler than deprecating the > > > > >> > > >> > first version of > > > > >> > > something. > > > > >> > > >> > > > > > >> > > >> > -A > > > > >> > > >> > > > > >> > > >> I think we are saying the same thing. In this case, > > > > >> > > >> deprecate = rip > > > > >> > it out. > > > > >> > > > > > > > >> > > > Are we saying that? We've got 6 working days of general > > > > >> > > > development > > > > >> > > time before we start locking down for a release. Can we > get > > > > >> > > the query > > > > >> > API > > > > >> > > implemented in that time? > > > > >> > > > > > > > >> > > > Regarding the specific licensing issue, Prachi is > looking > > > > >> > > > at what > > > > >> > happens > > > > >> > > when we remove the WSDLs. The server stubs are already in > > > > >> > > the code base, so in theory we shouldn't need the WSDLs to > be > > > > >> > > present > > > anyway. > > > > >> > > Prachi is looking at whether that's true. > > > > >> > > > > > > >> > > > > > > > >> > > > Ewan. > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > >
