Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ferncam1@gmail.com designates
 209.85.160.47 as permitted sender)
MIME-Version: 1.0
Sender: ferncam1@gmail.com
In-Reply-To: <55gdxj40escu12chv27j62l4.1344037630932@email.android.com>
References: <55gdxj40escu12chv27j62l4.1344037630932@email.android.com>
Date: Fri, 3 Aug 2012 16:55:10 -0700
Message-ID: 
 <CAARMrHUKO0NcTiY-CFvUYtLkmPQmoSq8pxmh9jToU=jQV3tg3w@mail.gmail.com>
Subject: Re: ec2 API compatibility (WSDL vs Query)
From: Adrian Cole <adrian.f.cole@gmail.com>
To: cloudstack-dev@incubator.apache.org,
	Ahmad Emneina <Ahmad.Emneina@citrix.com>
Cc: Prachi Damle <Prachi.Damle@citrix.com>
Content-Type: multipart/alternative; boundary=f46d042f941c29e88204c66542f7

--f46d042f941c29e88204c66542f7
Content-Type: text/plain; charset=ISO-8859-1

Certainly, a public endpoint is easier on devs than a work-in-progress
devstack.  I'm not sure I will have time to work through that process in
the short term.  I am happy to help test an existing endpoint and maintain
tests, though.

-A
On Aug 3, 2012 4:49 PM, "Ahmad Emneina" <Ahmad.Emneina@citrix.com> wrote:

> This sounds like thats the perfect job for devcloud. do an ant build-all
> from within devcloud and that should include building the awsapi/cloud
> bridge component. let us know what level of success you have.
> Adrian Cole <adrian.f.cole@gmail.com> wrote:
> I'm starting work on this here.
> http://code.google.com/p/jclouds/issues/detail?id=1056
>
> Note it would be easiest if we know of a public endpoint or easy-to-repeat
> install of cloudstack+cloudbridge (on master).  For example, I know
> Deltacloud provide a public endpoint for testing, refreshed on some
> interval.
>
> Current failures related to greenqloud are here, but since the focus is
> Apache CloudStack vs what was formerly released, I think it is more
> relevant tracking the above issue instead:
> http://code.google.com/p/jclouds/issues/detail?id=972
>
> On Thu, Aug 2, 2012 at 1:04 PM, Duncan Johnston Watt <
> duncan.johnstonwatt@cloudsoftcorp.com> wrote:
>
> > Adrian/All
> >
> > +1 to focusing on Query API.
> >
> > Best
> >
> > Duncan
> >
> > On 2 August 2012 22:01, Adrian Cole <ferncam1@gmail.com> wrote:
> >
> > > Sure thing!  I'll shoot instructions and results after lunch.
> > > On Aug 2, 2012 12:59 PM, "Ewan Mellor" <Ewan.Mellor@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: ferncam1@gmail.com [mailto:ferncam1@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.ponnaganti@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.Mellor@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: ferncam1@gmail.com [mailto:ferncam1@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.childers@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.Mellor@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: ferncam1@gmail.com [mailto:ferncam1@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.Mellor@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.childers@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.Mellor@eu.citrix.com>
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > >> -----Original Message-----
> > > > > > > > >> > > >> From: Chip Childers [mailto:
> > chip.childers@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.cole@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<
> http://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.
> >
>

--f46d042f941c29e88204c66542f7--