deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: BeeScale API announcement
Date Fri, 19 Aug 2011 22:13:20 GMT
Hi Martin,

first off, I am really glad that you wrote this up, and that your
experience with doing an independent implementation (first ever, in the
world, nah, the universe ;) of the Deltacloud API was so positive.

I'd love any more feedback around the API, be it around improving docs,
evolution of the API, or anything else. As a cloud provider, you
certainly have a different perspective of what should be offered in the
API, and how hard that is to implement natively.

On Fri, 2011-08-19 at 11:56 +0200, Martin Kopta wrote:
> I was unsure if 
> extension of outputs is allowed, but [4] made clear it isn't problem at 
> all.

In general, the stability guarantees that Deltacloud makes allow for
adding additional elements in the XML responses (and corresponding
changes to other output formats) That, though, is a mechanism for
evolving the DC API - we don't have anything in place for vendor
extensions. Having said that, we are more than happy to discuss and
adopt extensions to the 'official' API if Beescale needs them.

>  Most needed extension of output was GET /api/instances/<id>: added 
> were <cpu> and <memory> since BeeScale doesn't use predefined hardware 
> profiles and user sets those params at creation/modification of virtual 
> server. With that said, hardware profile wasn't used much. Only one is 
> available and it gives ranges for almost all params.

That was one of the intentions behind HWP: to make strict cases like EC2
_and_ very generic HWP where all dimensions can be chosen by the user.
Did you have to amend the API or could you make do with the current
mechanism of a generic HWP and instance-specific overrides for the
parameters in the HWP ?

> BeeScale API is available for all BeeScale users. After registration on 
> BeeScale (czech language only), user will get access to account 
> settings, where he can set BeeScale API on and gets his unique key. 
> Then, user may use the BeeScale API at with 
> credentials 'mail':'key'. Rest of usage is described by Deltacloud.

Cool .. if you want to, we can add that to the matrix at [1]

BTW, I just noticed that the Beescale API reports version '1.0.0-api' -
clients shouldn't rely on the version of the API, but if they do, it
would be better to report the version of Deltacloud that is implemented
(I assume '0.3.0')

> Choice of Deltacloud API as native API for BeeScale cloud was very 
> successful. Implementation went smoothly and the documentation was 
> especially great in comparion with other standards. Except few 
> misunderstandings, Deltacloud is comprehensible and easy to use. 

Again, I am really glad to hear that.

> However, I hope that after recent update of Deltacloud API not many 
> things will change for BeeScale API.

I hope so too ;) For the future, it would be great to get your input on
this list on API changes. That's probably the best way to ensure that
the Beescale API remains a valid implementation of Deltacloud.

One addition you might consider is adding a /drivers collection (in your
case, it would have one entry for Beescale) - though that is not part of
the official API yet, and we'll build out what is reported there in the
next release and formalize it.



View raw message