incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kopta <mko...@oldanygroup.cz>
Subject Re: BeeScale API announcement
Date Mon, 22 Aug 2011 10:55:23 GMT
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.

Mime
View raw message