Changes between Version 44 and Version 45 of AaronHelsinger/GAPI_AM_API_DRAFT

Timestamp:

04/12/12 10:48:50 (12 years ago)

Author:

Aaron Helsinger

Comment:

--

AaronHelsinger/GAPI_AM_API_DRAFT

@@ -266 +266 @@
 These states would be reported by various AM API methods, specifically !SliverStatus. And would be used in reasoning about valid operations in !PerformOperationalAction
 
-The AM API defines a few operational states with particular semantics. AMs are not required to support them for a given set of resources, but if they use them, they must follow the given semantics. AMs are however STRONGLY encouraged to support them, to provide maximum utility.
+The AM API defines a few operational states with particular semantics. AMs are not required to support them for a given set of resources, but if they use them, they must follow the given semantics. AMs are however STRONGLY encouraged to support them, to provide maximum utility. There is one state that AMs are required to support, `geni_pending_allocation`, for a sliver which has not been fully allocated and provisioned.
 
 Similarly, the API defines a few operational actions: these need not be supported. AMs are encouraged to support these if possible, but only if they can be supported following the defined semantics.
@@ -287 +287 @@
 `shutdown` is not an operational state for a sliver. The Shutdown() API method applies to an entire slice.
 
+Operational states are generally only valid for slivers which have been provisioned (`geni_provisioned` allocation state).
+
 GENI defined operational states:
+ - `geni_pending_allocation`: A wait state. The sliver is still being allocated and provisioned, and other operational states are not yet valid. For example, the sliver is in allocation state `geni_provisioned`, but has not been fully provisioned (e.g., the VM has not been fully imaged). Once the sliver has been fully allocated, the AM will transition the sliver to some other valid operational state, as specified by the advertised operational state machine. Common next states are `geni_notready`, `geni_ready`, and `geni_failed`.
  - `geni_notready`: A final state. The resource is not usable / accessible by the experimenter, and requires explicit experimenter action before it is usable/accessible by the experimenter. For some resources, `geni_start` will move the resource out of this state and towards `geni_ready`.
  - `geni_configuring`: A wait state. The resource is in process of changing to `geni_ready`, and on success will do so without additional experimenter action. For example, the resource may be powering on.