Changes between Version 8 and Version 9 of GAPI_AM_API_DRAFT

10/18/11 11:29:59 (13 years ago)
Aaron Helsinger




    v8 v9  
    1414  * Omni version 1.3 (released June 2011) added client software support for these changes.
    1515 B. New and changing proposal: Supporting flexible arguments and returns. Specifically, adding a property list to all calls, and making all returns be a property list.
    16  C. Undefined proposal: Support for !UpdateSliver.
     16 C. New and changing proposal: Add a new method: !UpdateSliver
    1717 D. Undefined: Support for clients adding slivers at an aggregate that already has 1 sliver for that slice, or deleting or renewing individual slivers.
    1818 E. Undefined: Tickets, otherwise known as negotiated reservations.
    3737=== Change Set C: !UpdateSliver ===
    39 This change is TBD.
     39This change set is new, not implemented, and currently under discussion.
     41 * Add a method !UpdateSliver, which adds, removes or modifies resources allocated the slice at the given aggregate, to match the new request RSpec supplied as an argument
     42 * See the discussion below.
    4144=== Change Set D: Slivers and Slivergroups ===
    43 This change is TBD.
     46This change is TBD. The current proposal is to do nothing. See the discussion below.
    4548=== Change Set E: Tickets ===
    47 This change is TBD.
     50This change is TBD. There is no concrete proposal yet on how to introduce tickets. See the discussion below.
    4952== Proposing Additional Changes ==
     397=== Change Set C: !UpdateSliver ===
     398''Note: This set of changes is currently under active discussion and has gotten no unofficial or official agreement.''
     400A common complaint among experimenters about the current AM API V1 is that there is no way to add or remove resources from a slice at an aggregate, without completely deleting the slice at that aggregate and recreating it, possibly losing resources to another experimenter and certainly losing state. This proposal aims to address that, by introducing a method to update the slice at an aggregate.
     402The [ SFA] calls for an !UpdateSlice method, "to request that additional resources—as specified in the RSpec—be allocated to the slice".
     404In the PlanetLab implementation of the SFA, !UpdateSliver is in fact a synonym for !CreateSliver - the server will ensure that your allocated resources match your request RSpec, adding, removing and modifying resources as needed. It immediately allocates and boots nodes to match the request RSpec.
     406The ProtoGENI CMV2 API has [ UpdateSliver], which is described as the way to "Request a change of resources for an existing sliver. The new set of resources that are desired are specified in the rspec." At ProtoGENI as at !PlanetLab, this method takes the full RSpec description of resources the experimenter wants, and the server computes the difference with what the experimenter already has. At ProtoGENI though, this method returns a ticket. The experimenter must then redeem the ticket to actually acquire the resources. Then the experimenter manually calls !RestartSliver as needed on nodes that need to be rebooted, when the experimenter is ready to do so. This takes an extra step, but gives the experimenter full control over which nodes are restarted and when.
     408Some key properties and differences of this method at those two aggregate code-bases, with a note on the alternatives. The community must discuss the options:
     409 - Takes the full description of what the experimenter wants, and the server computes the difference. Note that 2 experimenters with permissions to modify the slice (say, 2 students of a professor) could issue conflicting update calls on the same aggregate. And alternative would be that experimenters must compute the difference themselves, and would just specify the incremental changes they want in their reservation.
     410 - Atomic: either the full request succeeds, or it fails. The alternative would be that if the experimenter wanted 5 more nodes and only 3 were available, that the server could give you those 3.
     411 - The two implementations above differ on whether the changes are immediate or not. ProtoGENI uses tickets, allowing the experimenter to change their mind or coordinate their requests (See below). They also separate out reservation of the resources with restarting nodes. This allows the experimenter to control which nodes get rebooted and when. !PlanetLab in comparison handles all restarting of nodes for the experimenters, giving them a single operation to get their resources. This approach also more closely matches the behavior of !CreateSliver in the AM API V1.
     413''The community must discuss the alternatives above.''
     415The proposed new method:
     417struct UpdateSliver(string slice_urn,
     418                    string credentials[],
     419                    <GENIV3 request RSpec schema compliant XML string> rspec,
     420                    struct users[],
     421                    struct options)
     422Success Return:
     424   code=0
     425   value= <GENI V3 Manifest RSpec string>
     426   option = <None>
     430Proposed semantics:
     431 - RSpec argument is a complete request RSpec with the desired new end state for the slice at this aggregate. ''Open questions: Does the request schema support specifying sliver_ids or other attributes that were in the manifest RSpec, and which the experimenter might want or need to preserve in this RSpec?''
     432 - Atomic: the request either succeeds entirely or fails and the slice is not changed at the aggregate at all, with the aggregate returning a message indicating that it failed and why. Aggregates are encouraged to return enough information to allow the experimenter to modify the request such that it can succeed.
     433 - Resources are allocated and started or restarted immediately, on behalf of the experimenter (no tickets, and no separate call to restart the sliver)
     436=== Change Set D: Slivers and !SliverGroups ===
     437''Note: This set of changes is currently under active discussion and has gotten no unofficial or official agreement.''
     439''The current proposal in this change set is to do nothing. See the proposal for !UpdateSliver instead.''
     441The current AM API calls take a Slice URN, and operate on all resources under that ID at the given aggregate - all the resources for that slice at the aggregate are allocated, renewed, and deleted together. There is no provision for releasing some of the resources allocated to the slice at that aggregate, or for adding new resources to the reservation for that slice at a given aggregate.
     443This ties closely to the precise definition of a Slice vs a Sliver. The current AM API methods imply that a sliver represents all resources at an aggregate for a given slice. However, this does not match the definition that previous GENI documents have used, nor the functionality that experimenters desire.
     445''A sliver is the smallest set of resources at an aggregate that can be independently reserved and allocated. A given slice may contain multiple slivers at a single aggregate. A sliver may contain multiple components.''
     447As such, the current AM API methods in fact operate on a group of slivers.
     449This change set would provide a means for experimenters to operate on individual slivers within their slice at a given aggregate, or perhaps to define and operate on arbitrary groups of slivers at a given aggregate.
     451Specifically, this change would provide ways to:
     452 - Add resources to a slice at a given aggregate, where resources are already reserved - without having to delete and recreate the reservation at the aggregate. But for this capability, see the !UpdateSliver proposal above.
     453 - Delete specific resources (slivers) from a reservation at an aggregate, without losing other resources. For this capability, see the !UpdateSliver proposal above. Alternatively, !DeleteSliver could be modified to take ''either'' a {{{slice_urn}}} (as it does currently), or a {{{sliver_urn}}}, such as is returned in a manifest RSpec.
     454 - Renew the reservation on specific resources (slivers) within a reservation at an aggregate, while allowing other resource reservations to expire. However, it is unclear whether this particular function would be useful.
     455 - Support fine grained manipulation of resources in other future AM API calls (such as !StartSliver, !StopSliver, !RestartSliver). However, those other functions are not yet supported in the AM API.
     458=== Change Set E: Tickets ===
     459''Note: This set of changes is not defined, currently under active discussion and has gotten no unofficial or official agreement.''
     461The [ SFA] defines the concept of a ticket. SFA1.0 section 5.3 says "A component signs an RSpec to produce a ticket, indicating a promise by the component to bind resources to the ticket-holder at some point in time." Tickets are promises to allocate resources.
     463Tickets are used in the [ ProtoGENI CMV2 interface], and are discussed on their wiki [ here]. Tickets (and leases) are also used extensively in Orca. For details on the use of leases and tickets in Orca, see [ 'the Orca Book']. However, each of these uses of the notion of tickets differs.
     465Tickets would enable a number of useful and possibly critical features:
     466 - Brokers: 3rd parties consolidating, scheduling and allocating resources on behalf of a number of other aggregates
     467 - Lending resources to other experimenters
     468 - Coordinated or negotiated reservations: reserving resources from aggregate B only if aggregate A can give you a complementary resource. For example, a VLAN tag. This is related to stitching, both network stitching and the more general form.
     469 - Two phase commit reservations (similar to the above)
     470 - Scheduled reservations in the future
     471 - Giving experimenters explicit control over when resources are started, stopped, and restarted (see the discussion on !UpdateSliver above)
     473This change would introduce the concept of tickets, and new methods to use tickets. It requires:
     474 - a ticket schema
     475 - methods to get, redeem, split, and maybe return tickets
     476 - semantics for what promises a ticket provides, and what it means to redeem and return tickets
     477 - many other details.