| | 396 | |
| | 397 | === Change Set C: !UpdateSliver === |
| | 398 | ''Note: This set of changes is currently under active discussion and has gotten no unofficial or official agreement.'' |
| | 399 | |
| | 400 | A 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. |
| | 401 | |
| | 402 | The [http://svn.planet-lab.org/attachment/wiki/WikiStart/sfa.pdf SFA] calls for an !UpdateSlice method, "to request that additional resources—as specified in the RSpec—be allocated to the slice". |
| | 403 | |
| | 404 | In 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. |
| | 405 | |
| | 406 | The ProtoGENI CMV2 API has [http://www.protogeni.net/trac/protogeni/wiki/ComponentManagerAPIV2#UpdateSliver 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. |
| | 407 | |
| | 408 | Some 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. |
| | 412 | |
| | 413 | ''The community must discuss the alternatives above.'' |
| | 414 | |
| | 415 | The proposed new method: |
| | 416 | {{{ |
| | 417 | struct UpdateSliver(string slice_urn, |
| | 418 | string credentials[], |
| | 419 | <GENIV3 request RSpec schema compliant XML string> rspec, |
| | 420 | struct users[], |
| | 421 | struct options) |
| | 422 | Success Return: |
| | 423 | { |
| | 424 | code=0 |
| | 425 | value= <GENI V3 Manifest RSpec string> |
| | 426 | option = <None> |
| | 427 | } |
| | 428 | }}} |
| | 429 | |
| | 430 | Proposed 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) |
| | 434 | |
| | 435 | |
| | 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.'' |
| | 438 | |
| | 439 | ''The current proposal in this change set is to do nothing. See the proposal for !UpdateSliver instead.'' |
| | 440 | |
| | 441 | The 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. |
| | 442 | |
| | 443 | This 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. |
| | 444 | |
| | 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.'' |
| | 446 | |
| | 447 | As such, the current AM API methods in fact operate on a group of slivers. |
| | 448 | |
| | 449 | This 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. |
| | 450 | |
| | 451 | Specifically, 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. |
| | 456 | |
| | 457 | |
| | 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.'' |
| | 460 | |
| | 461 | The [http://svn.planet-lab.org/attachment/wiki/WikiStart/sfa.pdf 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. |
| | 462 | |
| | 463 | Tickets are used in the [http://www.protogeni.net/trac/protogeni/wiki/ComponentManagerAPIV2 ProtoGENI CMV2 interface], and are discussed on their wiki [http://www.protogeni.net/trac/protogeni/wiki/Tickets here]. Tickets (and leases) are also used extensively in Orca. For details on the use of leases and tickets in Orca, see [https://geni-orca.renci.org/trac/attachment/wiki/WikiStart/ORCA%20Book.pdf 'the Orca Book']. However, each of these uses of the notion of tickets differs. |
| | 464 | |
| | 465 | Tickets 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) |
| | 472 | |
| | 473 | This 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. |
