Changes between Version 5 and Version 6 of GAPI_AM_API_V3/CommonConcepts

Timestamp:

05/02/12 12:08:54 (12 years ago)

Author:

Aaron Helsinger

Comment:

--

GAPI_AM_API_V3/CommonConcepts

@@ -97 +97 @@
 One or more slivers are created by an aggregate when the experimenter calls Allocate(). This API encourages aggregates to independently manage each sliver, allowing experimenters to selectively Delete, Renew, or Provision each sliver. As such, these methods take a list of sliver urns (or a slice urn), and return a struct reporting results for each sliver URN independently. However, slivers at an aggregate may have interdependencies, and an individual aggregate may not be able to independently manage each sliver, without also modifying other related slivers. This API defines a number of aggregate configuration options returned by !GetVersion, and an option to many methods, allowing aggregates to advertise their behavior, and experimenters to request particular behavior.
 
- 1. `geni_single_allocation: <XML-RPC boolean 1/0, default 0>`: When performing one of (Describe, Allocate, Renew, Provision, Delete), the AM requires you to include either the slice urn or the urn of all the slivers in the same state. If you attempt to run one of those operations on just some slivers in a given state, the AM will return an error.
-For example, you must Provision all `geni_allocated` slivers at once: At an aggregate with `geni_single_allocation` true, if you supply a list of sliver URNs to Provision that is only 'some' of the `geni_allocated` slivers for this slice at this AM, then the AM will return an error. Similarly, such an aggregate would return an error from Describe if you request a set of sliver URNs that is only some of the `geni_provisioned` slivers.
-
- 2. `geni_allocate`: A case insensitive string, one of fixed set of possible values. Default is `geni_single`. This option defines whether this AM allows adding slivers to slices at an AM (i.e. calling Allocate() multiple times, without first deleting the allocated slivers). Possible values:
-  - `geni_single`: Performing multiple Allocates without a delete is an error condition because the aggregate only supports a single sliver per slice or does not allow incrementally adding new slivers. This is the AM API v2 behavior.
-  - `geni_disjoint`: Additional calls to Allocate must be disjoint from slivers allocated with previous calls (no references or dependencies on existing slivers). The topologies must be disjoint in that there can be no connection or other reference from one topology to the other.
+ 1. `geni_single_allocation: <XML-RPC boolean 1/0, default 0>`: When true (not default), when performing one of (`Describe`, `Allocate`, `Renew`, `Provision`, `Delete`), such an AM requires you to include either the slice urn or the urn of all the slivers in the same state. If you attempt to run one of those operations on just some slivers in a given state, such an AM will return an error. 
+For example, at an AM where `geni_single_allocation` is true you must `Provision` all `geni_allocated` slivers at once. If you supply a list of sliver URNs to `Provision` that is only 'some' of the `geni_allocated` slivers for this slice at this AM, then the AM will return an error. Similarly, such an aggregate would return an error from `Describe` if you request a set of sliver URNs that is only some of the `geni_provisioned` slivers.
+
+ 2. `geni_allocate`: A case insensitive string, one of fixed set of possible values. Default is `geni_single`. This option defines whether this AM allows adding slivers to slices at an AM (i.e. calling `Allocate()` multiple times, without first deleting the allocated slivers). Possible values:
+  - `geni_single`: Performing multiple `Allocate`s without a delete is an error condition because the aggregate only supports a single sliver per slice or does not allow incrementally adding new slivers. This is the AM API v2 behavior.
+  - `geni_disjoint`: Additional calls to `Allocate` must be disjoint from slivers allocated with previous calls (no references or dependencies on existing slivers). The topologies must be disjoint in that there can be no connection or other reference from one topology to the other.
   - `geni_many`: Multiple slivers can exist and be incrementally added, including those which connect or overlap in some way. New aggregates should strive for this capability.