API Discussion

  48 posts   Feedicon  
Replies: 47 - Last Post: June 19, 2009 13:42
by: raghavanachary
showing 1 - 20 of 48
« Previous 1 3
 
Posted: March 13, 2009 18:26 by enomaly
First of all, great work guys. My first impression is the API is very easy to understand and you've applied the RESTful principles beautifully.

The Creative Commons Attribution 3.0 License is a nice added touch although my concern about that particular license is its Attribution requirement. "You must attribute the work in the manner specified by the author or licensor" My guess is your looking for the widest adoption possible, I would say an unrestricted license may help propagate it's usage faster.

I see no reference to billing or cost. I think you're missing a big opportunity to include programmatic costing / metering. Something I have been pushing Amazon to do.

Another comment is there seems to be no load balancing reference, although the VNet or interface components might be sufficient.

I noticed no discussions on the API, so I thought I'd go ahead and be the first.
-
Reuven
Sun Strategic Advisor
Blog > www.elasticvapor.com
 
Posted: March 13, 2009 21:10 by Lew Tucker
Hi Reuven,
Thanks. We pushing for the widest adoption possible, but didn't feel that asking for attribution would slow that down.

In this current spec, you are right we don't cover APIs to get access to metering and billing information. I agree that we should.

In regards to load balancers, we envision that a user would simply create a front-end VNet connecting a load-balancer with the set of front-end machines.

Thanks for being the first in this discussion forum.
-Lew
 
Posted: March 14, 2009 05:42 by Tim Bray
First, at the meta-level: When this project becomes public, the atom feed will start to work. Which is the only thing that makes a forum usable for me.

Second, we need to make it clear that this API spec is not a finished product. We are building technology at a high rate of speed, obviously, but as with other potential implementors, much of the technology was already in place before the unified-API idea started getting traction. So we have a lot of flexibility, for a little while anyhow, in adopting corrections and improvements that other people come up with. That's one of the reasons we're taking this public before we turn our own offering on.

As for billing and load balancing; I'm a standards veteran and totally loathe the idea of trying to specify an API until there are real users and use-cases and work technology technology to base it on. So it'd be great to have proposals on how to do the billing API and so on, but it'd be even greater if the proposal included "...and it's this way because it has to address these issues that turned out to be important when we rolled one out."

-Tim
 
Posted: March 17, 2009 04:22 by Thorsten von Eicken
Congrats on a well specified API. On the topic of billing, we currently reverse engineer Amazon's billing and are displaying to users on our dashboard. We also use it for chargebacks and reselling situations. I know of another company that has an EC2 based offering that crawls amazon's billing web pages in order to display charges to their users. So this is definitely of interest today and not academic. Getting the operational API going is a higher priority however.
 
Posted: March 17, 2009 04:36 by Thorsten von Eicken

Comments after an initial read-through:

  • The REST, JSON, URLs for objects stuff is all very appreciated, also the definition (still incomplete in places) of states of objects, thanks!

    • I don't get the "deploy", "undeploy" stuff. What's the purpose? Doesn't is just make things more complicated. I don't see that we'd ever call deploy without calling start immediately thereafter. What are the cost implications of deploy without start? I hope the answer isn't more pricing complexity...

    • Hibernate is cute. How useful and implementable at scale is it? What is the pricing implication? More complexity, it seems...

    • Listing all resources recusively when listing a VDC is helpful, but I fear impractical. We'd be calling "GET VDC" once a minute for every VDC. That'll get expensive on your end quickly... Just imagine the Animoto VDC when they have 4000 servers running. Even with a few hundred servers it's a lot of stuff. I would much rather have ways to query for objects modified since a timestamp.

    • What does cloning a VM do? Does it clone all disks, all memory, and all processor state (i.e. running processes)? If not, what does it do?

    • What does a VM backup do?

    • I don't understand the role of the dns entries in an interface. Do you run a DNS service? Are these default DNS names you assign? But it seems these are PUTable.

    • Does a VM by default have no interface connected to anything? It's not quite clear.

    • You need an API that VMs can query to find out about their own state. There is params and user-data mentioned in some places - how does a VM get at it. You don't want to force users to put the keys to the kingdom onto each VM just so it can gets its init params. Also, it seems a VM needs to find out about its interfaces just so it can "up" them so it can talk to someone.

    • Is the only way to communicate with the outside world having a static IP or going through another VM acting as a firewall?

    • I'm not sure I understand the value of clusters. In the end, how does a cluster help me? It seems the only thing is having a "start all" / "stop all" call, which is not particularly useful. It seems this is an abstraction implemented in the wrong place that just complicated things.

Cheers and congrats for getting this posted! Thorsten

 
Posted: March 17, 2009 16:45 by Tim Bray
Lots of good question; I can address a few...

Deploy/undeploy. The notion is that you can tinker with the models as much as you want, and when you hit "deploy" the system attempts to fill in hardware to match your model. In our existing implementation, this can have noticeable latency. The two operations seemed logically distinct to us. You'd suggest doing an auto-"start" on every successful deploy? Hmmmm... I wonder what others thing?

> Listing all resources recusively when listing a VDC is helpful, but I fear impractical.
> We'd be calling "GET VDC" once a minute for every VDC.

So far, even for fairly complex deployments a VDC representation is only a few hundred K. So I'm not convinced it's impractical. But you can also do a GET on a VM's URI and loop through them all one at a time if that's more practical, and a VM representation will of course be much smaller.

> What does cloning a VM do?

You're right, this needs better specification. Cloning the running processes seems ambitious; the current implementation produces something that is deployed and will have the same post-boot state.

> Does a VM by default have no interface connected to anything? It's not quite clear.

It's unspecified. A service provider could arrange for a new VM to be pre-connected the way it's done in AWS, or not connected until the user asks for it. I think the API will cover either case.

> You need an API that VMs can query to find out about their own state.
> There is params and user-data mentioned in some places - how does a VM get at it.
> You don't want to force users to put the keys to the kingdom onto each VM just so it
> can gets its init params. Also, it seems a VM needs to find out about its interfaces just
> so it can "up" them so it can talk to someone.

Current design is that the content of vm.params is in a filesystem mounted on "/cloud" at boot-time. We're not sure whether this practice is worth being frozen into the API. As for finding out your interfaces, it seems the easiest way to do it is to use this API; it's designed for use in scripts from inside the VDC as well. So the params structure needs sufficient information for a machine to access the cloud API.

> Is the only way to communicate with the outside world having a static IP or going through
> another VM acting as a firewall?

At the moment. Is this sufficient?

> I'm not sure I understand the value of clusters.

* They can be units of access control; the person who makes the VDC could give others the right to start/stop machines
* They can be units of copy/cloning
* (Most interesting to me) they can be units to help automate scripting. You can write a script to iterate over all the VMs in the "Database" cluster, for example, to schedule a reboot or query state or something, without having to hardwire in the names of all the machines.






 
Posted: March 17, 2009 04:43 by Thorsten von Eicken

More comments:

  • How do I create a new volume? Specify its size? Can it be grown? Shrunk? Create a volume form snapshot but make the volume larger than the snapshot?

  • In a public address, what is the vm attribute? It says "Logical name of the VM to which this address is attached, if any.", but is that unique? Wouldn't the URL for the VM be the right content.

Thorsten

 
Posted: March 17, 2009 16:47 by Tim Bray
> How do I create a new volume? Specify its size? Can it be grown? Shrunk?
> Create a volume form snapshot but make the volume larger than the snapshot?

There's a create-volume URI on the top-level "space" object.

> In a public address, what is the vm attribute? It says "Logical name of the VM
> to which this address is attached, if any.", but is that unique? Wouldn't the URL
> for the VM be the right content.

You're right, I actually ran across this one on Sunday, will fix. And by the way, since you're participating in this discussion you're now an official REST expert, which means you have to say "URI" instead of "URL" Smile
 
Posted: March 18, 2009 14:51 by Craig McClanahan
>> How do I create a new volume? Specify its size? Can it be grown? Shrunk?
>> Create a volume form snapshot but make the volume larger than the snapshot?

> There's a create-volume URI on the top-level "space" object.

To expand upon this a little bit, in a cloud world there is no longer an important need to preallocate a specified size ... you use what you need at the time, which can grow and shrink as you store and delete data. When you create a volume from a snapshot (in the API, this operation is called a "clone"), the data will be stored in the new clone exactly as it was when the snapshot was taken, but subseqent to that it also can grow or shrink as you add and remove data from the volumes.

 
Posted: May 24, 2009 12:29 by Alexandre Jaquet
Hi,

Do you mean a volume is considerated as a data structure ? In the specs we can read that a volume is a physical entity

but how can you resize it if in a Java world you didn't manipulate it as a data structrure for resizing ?

Alexandre Jaquet
Java Consultant - ITAC
 
Posted: May 24, 2009 22:54 by Craig McClanahan
> Do you mean a volume is considerated as a data structure ? In the specs we can read that a volume is a physical entity

Per the definition on the main page, a Volume resource represents some storage accessible via WebDAV on a storage service. Whether this is a single physical disk volume, or allocated space on a cloud storage service, is up to the service implementor. In the case of the Sun Cloud, at least, it will certainly not be a "physical entity" in the sense of having a maximum physical size.

> but how can you resize it if in a Java world you didn't manipulate it as a data structrure for resizing ?

There is no need to "resize" a cloud storage volume, so no API is required to support this. It may be appropriate to request and impose a maximum size, in which case it might be useful to add a quota field. But this could also be part of a service-specific extension for storage services that have this as a feature.

Craig
 
Posted: May 25, 2009 20:42 by Alexandre Jaquet
"finally" the final implementation will be an extention of a framework like terracoda with the add value of storing and distribute computing for an underfined number of applications right (and have the capability to communicate with other cloud)?

Are they are already partner ?
 
Posted: March 18, 2009 14:32 by Kieran Kunhya
Hello,

You might want to include number of processor cores as a field in the table at this URL:

http://kenai.com/projects/suncloudapis/pages/CloudAPISpecificationResourceModels#Virtual_Machine_(VM)_[application/vnd.com.sun.cloud.VM+json]

(the square brackets in the link confuse the bbcode parser)

Also "uptime" might be useful.

Thanks.

Kieran.
 
Posted: March 18, 2009 14:50 by pchaganti
Nice job with the API! I would also like the billing information easily accessible. This is one of the top requests we currently get from our AWS customers. This also enables us to build better reporting.

thanks
 
Posted: March 18, 2009 14:54 by Craig McClanahan
> Nice job with the API! I would also like the billing information easily accessible. This is one of the top requests
> we currently get from our AWS customers. This also enables us to build better reporting.

Access to billing information (and performance information, for that matter) is definitely important. One of the areas we are currently exploring, but are not quite ready to publish yet, is a "metrics" service that makes this sort of information available.
 
Posted: May 30, 2009 12:22 by Alexandre Jaquet
Hi,

In the doc it's explained the following thing :

A VMTemplate represents a preconfigured virtual machine image that may be "cloned" in a Create Virtual Machine request, by specifying the URI of a particular template as the value of the from_template field.

How can a virtual machine can be loaded from an image ? Does an image is dumped from a previsous state ?

Thanks !
 
Posted: March 18, 2009 15:47 by calavera
Great job!! I'm not sure if I could wait for play with the api Smile

I found a little errata in the resource models document, http://kenai.com/projects/suncloudapis/pages/CloudAPISpecificationResourceModels. In the Public Address section where you write: The fact that this address address is static ... should be The fact that this address is static ...

Also, reading the VCD request document I've seen you are using the cluster name to clone it. I know it's unique but I think the URI could fit better by definition.
 
Posted: March 18, 2009 19:31 by Craig McClanahan
> Great job!! I'm not sure if I could wait for play with the api Smile

> I found a little errata in the resource models document, http://kenai.com/projects/suncloudapis/pages
> /CloudAPISpecificationResourceModels. In the Public Address section where you write: The fact that
> this address address is static ... should be The fact that this address is static ...

Thanks ... typo now fixed.

> Also, reading the VCD request document I've seen you are using the cluster name to clone it. I know it's
> unique but I think the URI could fit better by definition.

Yah, Tim caught a similar case like this when he was reviewing the docs on Monday. I need to go through them with a fine toothed comb ... all the references from one resource to another should be done with URIs, not names.

Craig
 
Posted: March 18, 2009 19:53 by calavera

I just came across another little typo mistake.

In this page http://kenai.com/projects/suncloudapis/pages/CloudAPIClusterRequests#Create_VM the response codes are 200 400 401... but the 200 should be a 201.

 
Posted: March 18, 2009 23:03 by b6n
per exchange on twitter with timbray:

would be great to see the api be truly restful rather than the current rpc style represented by the 'ops' sections. here are a couple of examples.

restful vm creation would be:
PUT /clusters/cluster1/vms/<name> {blob of json}

or
POST /clusters/cluster1/vms/ {blob of json} ; returning 201 Created with the uri of the new vm resource


restful change of state (start, stop, etc.) would be:
POST /clusters/cluster1/vms/FW01/state {'start'}


you might also consider changing how addresses are reported and managed. here's how we report them in chef/ohai:


"addresses": {
"fe80::223:12ff:fe55:575e": {
"scope": "Link",
"prefixlen": "64",
"family": "inet6"
},
"192.168.0.95": {
"broadcast": "192.168.0.255",
"netmask": "255.255.255.0",
"family": "inet"
},
"00:23:12:55:57:5e": {
"family": "lladdr"
}
}


bb (benjaminblack on twitter)

showing 1 - 20 of 48
« Previous 1 3
Replies: 47 - Last Post: June 19, 2009 13:42
by: raghavanachary
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2013, Oracle Corporation and/or its affiliates
(revision 20131025.e7cbc9d)
 
 
Close
loading
Please Confirm
Close