Lew Tucker
|
Posted: July 06, 2009 16:50 by Lew Tucker
|
|
Background - modeling vs resource creation The implementation of the Sun Cloud Platform uses a model-based approach to dynamically manage changes in resources. Through the UI, a user can drag-and-drop virtual machines, virtual networks, etc. onto a canvas and then hit “deploy”. In our internal tests, this has proved to be a popular feature since it allows users to develop and save a system model without actually deploying and being charged for using virtual resources. This was the original thinking behind having a “deploy” function in the current API. An API user can add multiple resources to a cluster, and later, cause the cluster to be deployed. However, after getting user feedback on the API, this has proven to be a source of confusion, potential user errors, and some troubling issues. For example, after a cluster of machines is deployed, an API user might decide to make a change to the configuration of one or more machines through the API. However, this change doesn't really take effect until deployed. So, what should the API return when this system is queried before it is re-deployed – the change to the model or the reality of the running machine? Do we need to keep two separate views of the resources: modeled and actual? For other implementors of this API, does this “model then deploy” approach make sense or just more difficult since additional state is required? Can we separate modeling from the API and keep it as part of the UI? Proposal The suggestion here is to streamline and simplify the API (and resolve this model vs reality problem) by entirely removing the “deploy action” on resources from the API. Of course, this changes the semantics of things such as “add VM to cluster” to mean immediately initiate the deployment of the VM and return a status URI that can be polled to see when it has been achieved. When the API creates a new resource, it is created. When someone queries a particular resource, they get the actual representation of the instantiated resource. So what about the model? Does the ability to create, save, and share a model go away? No. The user interface, or in fact, any number of different tools, can still be made to create and manipulate models. The API, just isn't needed for this. Once a tool has created a model, the API can be invoked to instantiate it. When a new resource is created by the API, the system allocates it. Using a status URI returned in response to the request, the API user can then query the system to determine when the system has completed the requested task. Model moves to disk Lastly, the primary purpose of a model is to capture a representation of a set of virtual resources so that the set can be saved, shared, and used as a template for an actual system. This is the purpose of an OVF file. So, we still have a model – it's simply stored on disk as a template, and manipulated by other tools. The role of the API is to create, modify, or destroy virtual resources and as such can use a model expressed in an OVF file as input. Comments welcome. |
Proposal: Model vs Reality in the API – a change in the semantics of resource creation
3 posts
Replies: 2 - Last Post: September 16, 2009 12:51
by: Tim Bray
by: Tim Bray
showing 1 - 3 of 3
Craig McClanahan
|
Posted: September 16, 2009 08:04 by Craig McClanahan
|
|
As you know, we have followed through on this proposal and removed the "deploy" operations from the API. However, during implementation, a question has come up, which you asked in your proposal, but isn't really answered. Assume that a user has an existing (and running) VM, and he/she submits a PUT request to update the allocated main memory size. This is just one example of a change that requires a reboot to take effect. This raises two questions: * Should this PUT operation trigger a reboot? I would suggest it should not, because there might also be other changes required (such as attaching to an additional VNet) that should also take place before a reboot is explicitly requested. * If I do a GET to refresh my representation of the VM *before* the reboot takes place, should the memory field contain the "before" value (the current reality) or the "after" value (what will become the current reality)? The latter seems more likely to meet user expectations, but would mean there is no way to retrieve current reality. Craig |
Tim Bray
|
Posted: September 16, 2009 12:51 by Tim Bray
|
|
I agree that the PUT should not trigger a reboot. I think that we've acknowledged that only one of reality and as-modeled is going to be visible through the API; I don't think that it makes a huge difference which. Consider the case of a person, not the one who's making the changes, coming in and doing a GET on the machine. If they see the needs-reboot flag, are they better off in the case where what they see is the actuals (accurate for the moment, but something, you don't know what, is about to change), or the model (something in here is inaccurate but I don't know what). The first case seems marginally more useful, so I'd probably argue for retrieving current reality not model; but once again, it doesn't feel like a big difference. |
Replies: 2 - Last Post: September 16, 2009 12:51
by: Tim Bray
by: Tim Bray
