| | 30 | |
| | 31 | === Meeting Summary === |
| | 32 | * We agreed to two change sets, completing the list of changes to include in AM API version 2. We will: |
| | 33 | * Adopt change set A for inclusion in AM API version 2: RSpecs are GENI schema XML |
| | 34 | * Adopt change set B for inclusion in AM API version 2: |
| | 35 | * All methods include a new 'options' XMLRPC struct argument with no required values, supporting aggregate innovation |
| | 36 | * All methods return an XMLRPC struct consisting of (1) a return 'code', (2) the return 'value' from API v1, and (3) a human readable 'output' on errors, plus optional aggregate specific entries |
| | 37 | * Discuss details on some parts of change set B |
| | 38 | * This discussion to continue at the coding sprint |
| | 39 | * Error codes: integers? or strings? (including a specific namespace rather than the more discrete and arbitrary integers) |
| | 40 | * Supporting multiple AM API versions: How can servers do this? Multiple URLs as at ProtoGENI? If so, how do aggregates advertise those versions/URLs? (Perhaps in !GetVersion?) |
| | 41 | * How are GENI error codes documented? A wiki page? |
| | 42 | * How are new aggregate-specific options or returns documented? XMLRPC introspection? New !GetVersion entries? |
| | 43 | * Define GENI error codes |
| | 44 | * Continue discussion of !UpdateSliver, slivers and sliver groups, and the addition of tickets on the geni developer mailing list |
| | 45 | * That discussion will also continue at the Coding Sprint session |
| | 46 | * We began the discussion of tickets, hearing details of the meaning of tickets, their semantics, and their lifecycle, from Rob Ricci, Ilia Baldine (channeling Jeff Chase), and Andy Bavier |
| | 47 | |
| | 48 | === Selected Discussion Points === |
| | 49 | * Change set A (RSpecs are XML) was adopted without discussion |
| | 50 | * Change set B (new options argument and new return structure) was adopted with minor discussion. |
| | 51 | * We must agree to and document GENI error codes |
| | 52 | * Error codes were proposed as integers, with the space divided by aggregate developer. That either wastes codes or limits or both, while also hiding in a translation table whose codes these are. Why not use strings? |
| | 53 | * On errors, maybe aggregates should return the version of the API that they speak? |
| | 54 | * Some aggregates will desire to speak multiple versions of the API |
| | 55 | * ProtoGENI uses distinct URLs to allow the client to indicate to the server which version they are speaking |
| | 56 | * Servers must then advertise those URLs to clients in some standard way |
| | 57 | * Clarification: the 'output' return is human-readable and not machine parsable |
| | 58 | * !UpdateSliver turned into a discussion of how resources get partitioned between aggregates and between slivers, which led into the discussion of slivers vs groups of slivers vs slices. We postponed this discussion. |
| | 59 | * Rob Ricci focused on the lifecycle of tickets. |
| | 60 | * Tickets support two phase commit |
| | 61 | * Tickets are a promise of resources, that make the resources unavailable to others |
| | 62 | * Tickets can be further delegated |
| | 63 | * In PG tickets are for specific resources, though they could be generic |
| | 64 | * In PG reservations either wholly succeed or fail; that decision is orthogonal to the use of tickets |
| | 65 | * Ilia Baldine / Jeff Chase described tickets in Orca as a contract |
| | 66 | * Tickets are a signed contract promising future resources for a particular time window |
| | 67 | * Tickets indicate what, where, how many, and other properties, restrictions, and whether they can be delegated |
| | 68 | * Tickets can be delegated, split |
| | 69 | * The ticket holder redeems the ticket at the resource provider to get the resources |
| | 70 | * Tickets may be for generic or specific resources |
| | 71 | * Tickets name the resource provider (the AM), which allows brokers. |
| | 72 | * Brokers allow aggregates to concentrate power, to collaborate on policy, etc |
| | 73 | * Larry Peterson expressed some concern with tickets because they are a promise, and all allocations are only best-effort in !PlanetLab |
| | 74 | * Andy Bavier of !PlanetLab described a desire to use tickets for future reservations |
| | 75 | * They are just experimenting with tickets now |
| | 76 | * They have no need for coordinated reservations |
| | 77 | * They do not want tickets mandated in the API because it adds overhead for them |
