| 723 | == Change Set AA: Batch `Allocate` == |
| 724 | Scheduling (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. |
| 725 | |
| 726 | In 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. |
| 727 | |
| 728 | In 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. |
| 748 | |