I'd support doing query only. If a significant user need for SOAP emerges we can re-evaluate with clear data on the use case or tool that needs it.
-kevin > -----Original Message----- > From: Duncan Johnston Watt > [mailto:duncan.johnstonw...@cloudsoftcorp.com] > Sent: Thursday, August 02, 2012 1:05 PM > To: cloudstack-dev@incubator.apache.org > Cc: Prachi Damle > Subject: Re: ec2 API compatibility (WSDL vs Query) > > Adrian/All > > +1 to focusing on Query API. > > Best > > Duncan > > On 2 August 2012 22:01, Adrian Cole <fernc...@gmail.com> wrote: > > > Sure thing! I'll shoot instructions and results after lunch. > > On Aug 2, 2012 12:59 PM, "Ewan Mellor" <ewan.mel...@eu.citrix.com> > wrote: > > > > > 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. > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Duncan Johnston-Watt > CEO | Cloudsoft Corporation > > Twitter | @duncanjw > Mobile | +44 777 190 2653 > Skype | duncan_johnstonwatt > Linkedin | www.linkedin.com/in/duncanjohnstonwatt > > Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. > Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP > > This e-mail message is confidential and for use by the addressee only. If the > message is received by anyone other than the addressee, please return the > message to the sender by replying to it and then delete the message from > your computer. Internet e-mails are not necessarily secure. Cloudsoft > Corporation Limited does not accept responsibility for changes made to this > message after it was sent. > > Whilst all reasonable care has been taken to avoid the transmission of > viruses, it is the responsibility of the recipient to ensure that the onward > transmission, opening or use of this message and any attachments will not > adversely affect its systems or data. No responsibility is accepted by > Cloudsoft Corporation Limited in this regard and the recipient should carry > out such virus and other checks as it considers appropriate.
