Hello David, On 08/20/2011 12:13 AM, David Lutterkort wrote:
I'd love any more feedback around the API, be it around improving docs, evolution of the API, or anything else.
I am very glad to hear that.
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 ?
Well, BeeScale has 'limits' and each user has some limit (trial, default, dodger, tester, ..). Upon limit of logged user, hardware profile is generated. There is one fixed param - architecture, and variable params - storage, cpu and memory. Ranges for variable params are defined by limit of currently logged user. So, HWP of Deltacloud is alright for BeeScale usage.
Cool .. if you want to, we can add that to the matrix at [1]
That would be great. * cloud: BeeScale * driver: beescale * username: username * password: BeeScale API key * notes: Access to API is disabled by default. Enable in account settings.
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')
Fixed. I have set 0.3.0.
... 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.
Summarized bellow.
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.
I copyied syntax from mock driver and implemented 'drivers' collection into BeeScale API. About API changes ================= Because Deltacloud recetly updated, here are my thoughts on that move. I speak about Deltacloud API specification. This has absolutely nothing to do with the Deltacloud Daemon, Client or Library. * I am not sure, what is the current version of Deltacloud API. Is it still 0.3.0? Why it is not written in http://incubator.apache.org/deltacloud/api.html? * I am missing a changelog of Deltacloud API. Just the notice that there is new version including this and that would be enough. * I didn't really understand 'Features'. I haven't implemented that in BeeScale API. Do I have to add that? * Keys - seems nice, but again, I didn't really understand. BeeScale has - username (root) and password for each virtual machine and vnc port and password for each virtual machine. User also may store his ssh key in account settings, and that key will be copyied into every new/modified machine. Is the 'Keys' collection useful for any of that? * Blobs - no idea what are they for. I guess I don't really need them. * I like the <authetication> in instances. This allows me to remove tags <password> and <vnc> and do something like <authentication type="password"> <login> <username>root</username> <password>pwd</password> </login> <vnc> <port>5902</port> <password>pwd</password> </vnc> </authentication> I like this. * I noticed 'instance_profile'. Is this a way to summarize chosen values in variable range params in used HWP? Now I use <cpu> and <memory> tags for that in <instance>. * Storage resources - this seems to be a problem. BeeScale allows users to have disks - based either on platform (preinstalled OS) or raw data disks. The only difference is human description of that disk. And I used <images> collection in following manner: there are resources with id disk-[id] and resources platform-[id]. The disk-id resources are created vdisks belonging to user. The platform-id are resources, which may be copyied to create a new disk-id resource. In case of specifying platform-id as image-id while creating a new vserver, new vdisk is created quietly, and then used. Problems are these: * Currently, I am unable to attach/dettach disks to running vms, so the <storage_volumes> collection is completely useless to me. * Using <images> for user disks AND available platforms looks like abusing the concept, but I guess I haven't got any other choice. * In BeeScale, user may start vserver with up to four disks. And the primary disk may be even a storage disk. There is no way to archive that with current DC specs. I probably will use some sort of extension like image-id_2=[ID]&image-id_3=[ID].. Thanks for you interest, Martin PS: Sorry for the mess I caused in your list.
