Changes between Version 107 and Version 108 of GAPI_AM_API_DRAFT


Ignore:
Timestamp:
02/11/14 21:09:56 (6 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GAPI_AM_API_DRAFT

    v107 v108  
    658658Only slivers in the `geni_ready` state may be imaged. While the image is being created, the sliver will be in a new operational state, `geni_imaging`. While the sliver is in this state, no operational actions are permitted, and at some aggregates, the sliver may be inaccessible. Note that at some aggregates, creating an image may disrupt the running and state of the resource. When imaging is complete (successfully or due to error), the operational state transitions back to `geni_ready`.
    659659
    660 The aggregate will email the user who created the snapshot at the email address found in the user's certificate, providing status and results.
     660The aggregate will contact the user who created the snapshot, typically at the email address found in the user's certificate, providing status and results.
    661661
    662662=== `DeleteImage` ===
     
    720720 - Associates the image with the project/sub slice authority of the slice for which the image was imported
    721721 - '''FIXME''': Makes the image public? Private? Does the experimenter get to say or change it?
    722  - Emails the 'creator' with the new URN and URL for the local copy of the image
     722 - Contacts the 'creator' with the new URN and URL for the local copy of the image (typically via email)
    723723
    724724When an image is imported to another aggregate, the experimenter that imports the image is treated as the local image "creator", and the slice in which they import the image determines the local project / sub-slice authority for controlling local access to the image.
     
    786786Scheduling (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.
    787787
    788 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.
     788In this proposal, an experimenter submits a resource request (via `Allocate`), but does not immediately receive a manifest. Instead, the aggregate contacts the experimenter (typically via email) 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.
    789789
    790790In detail:
     
    802802 - `Delete` on a batch requested sliver cancels the request, making the sliver `geni_unallocated`
    803803 - If a time was specified in `geni_when_ready` and the resources have not become available, then:
    804   - 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)
     804  - The aggregate shall contact the requester (typically using the email address in the client certificate), specifying that the request could not be satisfied (including the slice urn and sliver urn)
    805805  - The sliver becomes `geni_unallocated`
    806806 - Otherwise, when the resources become available:
    807   - 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.
    808   - 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
     807  - 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 notification and respond. Typically at least 1 business day.
     808  - The aggregate shall contact the requester (typically 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
    809809 - 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.
    810810