Minutesfrom09Sep2009

ProtoGENI Project Meeting, 9 Sep 2009

Who/When

• attendees: Rob, Jon, Gary, Leigh (phone)
• start @ 1:45 PM
• end @ 2:30 PM

Component Manager API

Continued from yesterday's discussion. We proposed improvements to the second of the previous set of sliver states, and reached tentative agreement on a workable solution. The main modifications are:

• The SliverTicket operation and its associated state transition was found to contribute significant confusion but little or no value, and should be deleted.
• A new UpdateSliver operation is introduced, which requires an existing sliver and a new RSpec, and returns a new ticket if successful (with a corresponding transition to the Sliver and ticket state).
• The UpdateTicket operation while in the Sliver and ticket state might be useful in advanced cases, but is also likely to add complexity to the implementation. We will deliberately omit it for now, because it can presumably be reintroduced later without disturbing the rest of the API.

New proposal

The state diagram for the system after the meeting is:

Observations

The following properties were either noted during the meeting, or are obvious inferences from the discussion:

• Tickets are consumed during redemption, although the underlying promise of resources is retained within the sliver.
• The complete list of events defined within the API which can create a new valid ticket are:
  1. A successful call to GetTicket.
  2. A successful call to UpdateSliver.
  3. A successful call to DeleteSliver.
• The complete list of events defined within the API which can cause an existing ticket to become invalid are:
  1. A successful call to ReleaseTicket.
  2. A successful call to RedeemTicket.
  3. A successful call to DeleteSlice.
  4. Reaching the expiry time of the ticket.
• Any (slice, component manager) pair has exactly zero or one instantiated sliver.
• Any (slice, component manager) pair has exactly zero or one valid ticket.
• It is always possible to invoke some sequence of Resolve calls to determine the state of a slice (and sliver and ticket, if they exist) without changing that state.
  • In particular, Resolve on the slice URN yields the sliver URN if a sliver exists, and the ticket URN if a ticket exists. All four cases (neither sliver nor ticket; ticket but not sliver; sliver but not ticket; both sliver and ticket) are possible.
  • Resolve on a valid sliver URN gives a complete description of the sliver resources, including the URNs of all components in the sliver and the expiry time of the sliver. The precise form of this information is left to be determined, but it is explicitly not a ticket. (It is possible that much of the content might share the same form as ticket contents, but the result is not signed and is not a credential.) It is possible that the result might be the sliver manifest.
  • Resolve on a valid ticket URN yields a duplicate copy of that ticket.
• DeleteSliver shuts down a sliver, and returns a ticket for whatever remains of the original promise of resources. This is a new ticket, not merely a copy of the original ticket (which became invalid when it was redeemed). Although the resources promised by the ticket will typically be identical to the resources in the original ticket, the user should expect the contents of the ticket to have changed from those in the original. (For instance, this is a sensible time for the component manager to modify the "must be redeemed by" time on the original promise of resources.)
• DeleteSlice is always possible from any state. Any existing sliver is destroyed, and any existing ticket is invalidated.
• We believe that the above guarantees the property that the client can always recover the state of the slice, including the following cases:
  1. The result of a previous operation was not successfully received by the client.
  2. A temporary network partition.
  3. The state of a slice, sliver or ticket was changed by another user.
  4. A user obtains a ticket but then "forgets" it (e.g. because of a system malfunction or user error).
• No DeleteSliver operation has been defined as legal in the Sliver and ticket state. Note, however, that both ReleaseTicket followed by DeleteSliver, and RedeemTicket followed by DeleteSliver are legal, well-defined, and potentially useful; the loss of atomicity does not appear to be harmful.

DeleteSlice (which deletes both the sliver and the ticket) is also possible.

Advantages

• A two-phase commit is possible as long as:
  1. a sliver is instantiated, and
  2. the rollback resources are those currently existing as the sliver.
• This scheme is essentially the simplest we have proposed which guarantees two-phase commits (albeit in restricted circumstances). In particular:
  • It is simple enough that we all appear to understand what the model means after one meeting.
  • We believe that it is possible to implement this API without excessive complication in the component manager.
  • There are no no-ops or useless transitions.
• The scheme appears to be complete enough to describe "normal" operations. We ran through a small number of example scenarios, and the operations described appeared to be sufficient (including cases which required recovery from component failure).

Disadvantages

• No two-phase commit on promises for future resources is possible.
• UpdateTicket in the Sliver and ticket state will not be implemented at this time.
• There is no atomic transition from the Sliver and ticket state to Ticket.

Since it is not possible to address these potential drawbacks without introducing additional complexity, it seems to be a reasonable compromise to attempt to implement a prototype of the API as it is, and modify the interface if and when experience proves it to be insufficient.