enomaly
|
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 |
API Discussion
29 topics, 131 posts
» Share this
Replies: 47 - Last Post: June 19, 2009 13:42
by: raghavanachary
by: raghavanachary
Lew Tucker
|
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 |
Tim Bray
|
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 |
Thorsten von Eicken
|
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. |
|
Thorsten von Eicken
|
Posted: March 17, 2009 04:36 by Thorsten von Eicken
|
|
Comments after an initial read-through:
Cheers and congrats for getting this posted! Thorsten |
|
Tim Bray
|
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. |
|
Thorsten von Eicken
|
Posted: March 17, 2009 04:43 by Thorsten von Eicken
|
|
More comments:
Thorsten |
|
Tim Bray
|
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" 
|
Craig McClanahan
|
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. |
Alexandre Jaquet
|
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 |
|
Craig McClanahan
|
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 |
|
Alexandre Jaquet
|
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 ? |
|
Kieran Kunhya
|
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. |
|
Craig McClanahan
|
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. |
|
Alexandre Jaquet
|
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 ! |
calavera
|
Posted: March 18, 2009 15:47 by calavera
|
|
Great job!! I'm not sure if I could wait for play with the api 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. |
|
Craig McClanahan
|
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 |
|
calavera
|
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. |
|
b6n
|
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) |
Replies: 47 - Last Post: June 19, 2009 13:42
by: raghavanachary
by: raghavanachary
