Changes between Version 102 and Version 103 of GAPI_AM_API_DRAFT

01/31/14 16:46:03 (7 years ago)
Aaron Helsinger




    v102 v103  
     723== Change Set AA: Batch `Allocate` ==
     724Scheduling (see above) is complicated. Often, what an experimenter really wants is to get a particular set of resources whenever they are available. This change set proposes a way for a client to submit an asynchronous request for resources.
     726In this proposal, an experimenter submits a resource request (via `Allocate`), but does not immediately receive a manifest. Instead, the aggregate sends an email to the experimenter when and if the requested resources are available. At that time, the resources are `geni_allocated` and the experimenter can `Provision` and use the resources as usual.
     728In detail:
     729 - Add a new option to `Allocate`: `geni_when_ready`. If supplied, the experimenter is requesting the resources described in the request RSpec whenever they become available. The value of `geni_when_ready` may be None (empty), meaning that the experimenter wants these resources however long it takes to get them. If the value is a datetime, then the experimenter wants these resources only if they become available by the specified date.
     730 - If an aggregate does not support this option, it will ignore it, and either allocate the resources immediately, or fail the request (with an `UNAVAILABLE` error).
     731 - The return from `Allocate` when this option is accepted is different than usual:
     732  - The `geni_rspec` will be the request rspec as submitted, not a manifest RSpec
     733  - The `geni_slivers` list will contain a single sliver. This sliver identifies this new request (distinguishing it from other resource reservations in the same slice at the same aggregate, if any).
     734   - `geni_expires` is in general not defined, but will be the time specified by `geni_when_ready` if any
     735   - `geni_allocation_status` will not be `geni_allocated`, but a new allocation state: `geni_batch_requested`
     736 - Add a new allocation state, `geni_batch_requested`: The single sliver that results from a call to `Allocate` with the `geni_when_ready` option will be in the `geni_batch_requested` state until:
     737  - The aggregate can allocate the resource (and the sliver(s) become `geni_allocated`), or
     738  - The experimenter calls `Delete` on the sliver, and the sliver becomes `geni_unallocated`
     739 - `Update` on a batch requested sliver is legal, modifying the request that has been batched. `geni_when_ready` is not accepted in `Update`.
     740 - `Delete` on a batch requested sliver cancels the request, making the sliver `geni_unallocated`
     741 - If a time was specified in `geni_when_ready` and the resources have not become available, then:
     742  - The aggregate shall email the requester (using the email address in the client certificate), specifying that the request could not be satisfied (including the slice urn and sliver urn)
     743  - The sliver becomes `geni_unallocated`
     744 - Otherwise, when the resources become available:
     745  - The resources are reserved and change to `geni_allocated` as usual. The expiration time should be larger than for usual allocated resources, to allow time for the experimenter to receive the email and respond. Typically at least 1 business day.
     746  - The aggregate shall email the requester (using the email address in the client certificate), specifying that the request has been satisfied, including the usual return structure from `Allocate` plus the slice URN and aggregate URN
     747 - Once a batched request has been made `geni_allocated`, it behaves like any other set of allocated slivers. You can call `Update`, `Renew`, `Delete`, or `Provision` on it as usual.
    723749== Older Proposals ==
    724750Older proposals, withdrawn, superseded, or postponed: