Changes between Version 53 and Version 54 of GAPI_AM_API_DRAFT

Timestamp:

05/04/12 16:21:01 (12 years ago)

Author:

Aaron Helsinger

Comment:

--

GAPI_AM_API_DRAFT

@@ -169 +169 @@
  2. `geni_allocated` (alternatively called 'offered' or 'promised'). The sliver exists, defines particular resources, and is in a sliver. The aggregate has not (if possible) done any time consuming or expensive work to instantiate the resources, provision them, or make it difficult to revert the slice to the state prior to allocating this sliver. This state is what the aggregate is offering the experimenter.
  3. `geni_provisioned`. The aggregate has started instantiating resources, and otherwise making changes to resources and the slice to make the resources available to the experimenter. At this point, operational states are valid to specify further when the resources are available for experimenter use.
-
+{{{
+#!comment
 plus in select situations:
 
  4. `geni_failed`: A call to `Provision` failed for this sliver. The sliver is in indeterminate state. Check the `geni_error` return if provided, or call `Status`. The sliver may require operator action to recover it. 
-
+}}}
 The key change is the addition of state 2, representing resources that have been allocated to a slice without provisioning the resources. This represents a cheap and un-doable resource allocation, such as we previously discussed in the context of tickets. This compares reasonably well to the 'transaction' proposal written up by Gary Wong (http://www.protogeni.net/trac/protogeni/wiki/AM_API_proposals). When a sliver is created and moved into state 2 (`geni_allocated`), the aggregate produces a manifest RSpec identifying which resources are included in the sliver. This is something like the current !CreateSliver, except that it does not provision nor start the resources. These resources are exclusively available to the containing sliver, but are not ready for use. In particular, allocating a sliver should be a cheap and quick operation, which the aggregate can readily un-do without impacting the state of slivers which are fully provisioned. For some aggregates, transitioning to this state may be a no-op.
 
@@ -189 +190 @@
  5. `Provision` moves 1+ slivers from state 2 (`geni_allocated`) to state 3 (`geni_provisioned`). This is some of what version 2 !CreateSliver did. Note however that this does not 'start' the resources, or otherwise change their operational state. This method only fully instantiates the resources in the slice. This may be a no-op for some aggregates or resources.
 
-When `Provision` fails for only some slivers, and `geni_best_effort` option was supplied, the aggregate will return the status of each requested sliver individually. The `geni_allocation_state` for slivers that failed may remain `geni_allocated`. This typically suggests that the experimenter may retry the call. The state may instead become `geni_unallocated`. This indicates that the sliver is being deleted, and all resource reservations under this sliver have been freed. Alternatively, the state may be `geni_failed`, indicating an error or refusal by the AM to complete the operation. An operator may need to intervene. Alternatively, the sliver may shortly self transition and become either `geni_allocated` again or `geni_unallocated`.
-
+When `Provision` fails for only some slivers, and `geni_best_effort` option was supplied, the aggregate will return the status of each requested sliver individually. The `geni_allocation_state` for slivers that failed will remain `geni_allocated`. This typically suggests that the experimenter may retry the call. For some aggregates or resource types, the sliver may be 'dead', and `Provision` may never succeed. Experimenters should check `geni_error` for more information.
+{{{
+#!comment
+When `Provision` fails for only some slivers, and `geni_best_effort` option was supplied, the aggregate will return the status of each requested sliver individually. The `geni_allocation_state` for slivers that failed may remain `geni_allocated`. This typically suggests that the experimenter may retry the call. The state may instead become `geni_unallocated`. This indicates that the sliver is being deleted, and all resource reservations under this sliver have been freed. Alternatively, the state may be `geni_failed`, indicating an error or refusal by the AM to complete the operation. An operator may need to intervene. Alternatively, the sliver may shortly self transition and become either `geni_allocated` again or `geni_unallocated`. Experimenters should check `geni_error` for more information.
+}}}
 These states apply to each sliver individually. Logically, the state transition methods then take a single sliver URN. For convenience, these methods accept a list of sliver URNs, or a slice URN as a simple alias for all slivers in this slice at this aggregate.