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 http://beescale.com/api 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. cheers, David [1] http://incubator.apache.org/deltacloud/documentation.html
