Version 77 (modified by 12 years ago) (diff) | ,
---|
- GENI Aggregate Manager API Draft Revisions
- Change Sets Adopted in GENI Aggregate Manager API version 3
- Proposed Changes for GENI Aggregate Manager API version 4
- Changes Not Included
GENI Aggregate Manager API Draft Revisions
This page documents DRAFT revisions to the GENI Aggregate Manager API, proposed for the next version of the API. As indicated below, some of the revisions documented here have been discussed on the GENI developer mailing list, and during at least one GEC. Other revisions are in early discussions and subject to change or abandonment.
The GENI Aggregate Manager API allows aggregates to advertise resources and to allocate resources to Slices in the form of Slivers. A Sliver is a set of resources allocated by one Aggregate to one Slice. See below for a proposed complete definition.
The current officially adopted version of the API is 3 and is documented on the main API page.
API Version 3 was adopted based on changes previously listed on this page. Those changes have been removed from this page, and are now documented on a separate page. They are detailed below.
API Version 2 was adopted based on changes previously listed on this page. Those changes have been removed from this page, and are now documented on a separate page. They include:
- RSpec related changes, specifying that RSpecs are XML following GENI standard schemas.
- Since June 2011, the latest software from ProtoGENI and SFA (as of code tag 1.0-24) has complied with these changes.
- Omni version 1.3 (released June 2011) added client software support for these changes.
- Supporting flexible arguments and returns. Specifically, adding a property list to all calls, and making all returns be a property list.
This page documents proposed changes for AM API version 4. These changes are grouped into sets. API Version 4 will be the collection of changes from the change sets below which we next agree on. Change sets still under discussion will then be targeted at a future release.
Proposing Additional Changes
GENI community members are encouraged to propose changes to the GENI Aggregate Manager API.
Technical discussions are generally held on the Developers mailing list
Specific questions may be directed to the software team at the GPO (Tom Mitchell, Aaron Helsinger, and Sarah Edwards) at {tmitchel, ahelsing, sedwards} at geni.net
Change Sets Adopted in GENI Aggregate Manager API version 3
Version 3 has been adopted.
Details of the change sets included in AM API version 3 are at the v3 Deltas page.
Proposals adopted after GEC13:
- Change Set D: Slivers: Change methods to clarify that there may be multiple slivers per slice at an AM, and to allow operating on individual slivers
- Change Set F3: Sliver Allocation States and methods
- Change Set F4: Method to perform Sliver Operational actions
- Change Set F5: Sliver Operational States
- Change Set M: New method signatures, incorporating all previous adopted change sets
Proposals adopted at GEC13:
- ADOPTED: Change Set G: Generalize the credentials argument, allowing ABAC support
- ADOPTED: Change Set I1: SliversStatus return structure includes sliver expiration
- ADOPTED with changes: Change Set I2: SliversStatus return includes SSH logins/key for nodes that support SSH access
- ADOPTED: Change Set I3: CreateSlivers return becomes a struct, adds sliver expiration
- ADOPTED: Change Set K: Standardize certificate contents, etc.
- Include a real serial number, holder email, holder uuid, and optionally authority URL in certificates
- Define slice ID as the UUID plus URN in slice certificates
- Define slice name, sliver name, and user name restrictions, and similar for URNs
- Publish schemas for credentials and certificates
Proposed Changes for GENI Aggregate Manager API version 4
A key feature desired by experimenters, but not yet included in the Aggregate Manager API, is the ability to update a reservation in place, without losing the existing reservation. At times, this has been called UpdateSlivers. There is not currently an acceptable proposal for this feature that has been circulated.
Change Set N: Add information to GetVersion
This change set adds some additional information to the return from GetVersion
.
Change Set N1: Add geni_am_code_version
Aggregates use varying ways to identify the software version their AM uses. PlanetLab and ProtoGENI use code_tag
, Orca uses orca_version
, and FOAM
uses foam_version
. Automatically identifying software versions is important for monitoring and GENI operations. Aggregates are therefore strongly encouraged to advertise their current software revision using this standard field, though for security reasons some aggregates may choose not to do so.
This change set proposes adding geni_am_code_version
to the return from GetVersion
.
- The field is optional. Aggregate developers are expected to include this option, but site operators may select not to expose it.
- The value is a string.
- Legal characters are: alphanumeric, space,
-
(hyphen),.
,:
(colon),#
,_
(underscore),+
,(
,)
- Regular expression:
'^[a-zA-Z0-9-\.:#_\+\(\)]+$'
Change Set N2: Add geni_am_type
Aggregates are allowed to include AM specific return values, or even implement custom methods as part of the same interface.
Currently, there is no consistent way to identify what type of aggregate a given instance is, so as to know what additional attributes or options may be used. This proposal would add a way for aggregates to identify what kind of aggregate this is, and therefore what aggregate specific options or returns are applicable. Aggregates of aggregates may identify as multiple types. One of those types would indicate that this is such an aggregate of aggregates, and other listed types would indicate that clients may interact with the aggregate as though it is any of the listed types.
This change set proposes adding geni_am_type
to the return from GetVersion
.
- The field is required.
- The value is a list of strings, of length at least one. It should generally be a list of length 1. Aggregates of aggregates may list multiple types.
- Legal characters: alphanumeric
- Values should be one of the defined GENI AM types if applicable, as defined by the AM API geni-am-types.xml. (As of this proposal, one of
orca
,foam
,protogeni
,sfa
. More GENI AM types may be added in the future.)
Change Set N3: Use consistent types and prefixes
Make am_type
, geni_am_type
, and AM specific prefixes for new options consistent.
The AM API specifies an am_type
field as part of the code
in the basic return structure. This field has a set of prescribed values.
An earlier proposal adds a geni_am_type
return to GetVersion
.
The AM API encourages AM specific options and returns. These options and returns should have unique names, but the API does not specify how to ensure this.
This proposal aims to standardize these fields.
am_type
and geni_am_type
:
- The value is a string.
- Legal characters: alphanumeric
- Values should be one of the defined GENI AM types if applicable, as defined by the AM API geni-am-types.xml. (As of this proposal, one of
orca
,foam
,protogeni
,sfa
. More GENI AM types may be added in the future.)
Aggregate specific options and return attributes should be named with a prefix denoting the aggregate type. It should be the same as the am_type
and geni_am_type
for this aggregate. Therefore, character restrictions are:
- The value is a string.
- Legal characters: alphanumeric
- Values should be one of the defined GENI AM types if applicable, as defined by the AM API geni-am-types.xml. (As of this proposal, one of
orca
,foam
,protogeni
,sfa
. More GENI AM types may be added in the future.)
For example: ProtoGENI includes an AM-specific status in the v2 API return from SliverStatus
called pg_status
. By this proposal, that attribute should be renamed protogeni_status
.
Change Set O: Refine character restrictions
Change Set O1: Allow other characters in sliver names
Currently we heavily constrain legal characters in the 'name' portion of sliver URNs. See GeniApiIdentifiers. This is awkward. In particular characters like periods, and underscores are not allowed, but are very useful as separators.
This change set proposes modifying the name portion of the URN rules as follows. Note that these changes loosen existing restrictions, and so are backwards compatible (existing sliver names remain legal).
Sliver:
- May use only alphanumeric characters plus hyphen, underscore, or period:
'^[a-zA-Z0-9-_\.]+$'
Change Set O2: Explicitly define legal characters in some strings
Various fields in the AM API specification are defined only as strings, without explicit limits on legal characters. This makes it awkward to pass these values to and from scripts. In particular, many fields should only be alphanumeric, plus some limited number of separator characters.
This change set proposes constraining several options/return values that are currently defined only as 'string'.
- From
getversion
andlistresources
anddescribe
, the RSpectype
:
May use only alphanumeric characters plus hyphen, underscore, period, or colon; alphanumeric only in first character.
'^[a-zA-Z0-9][a-zA-Z0-9-_\.:]*$'
- From
getversion
andlistresources
anddescribe
, the RSpecversion
:
May use only alphanumeric characters plus hyphen, underscore, period, or colon; alphanumeric only in first character.
'^[a-zA-Z0-9][a-zA-Z0-9-_\.:]*$'
- From
getversion
, the RSpecschema
, andnamespace
: Any character valid in a URL (see e.g. http://www.w3.org/Addressing/URL/url-spec.txt)
- From
getversion
and thecredentials
argument, the credentialgeni_type
:
May use only alphanumeric characters plus hyphen, underscore, period, or colon; alphanumeric only in first character.
'^[a-zA-Z0-9][a-zA-Z0-9-_\.:]*$'
- From the return of multiple methods,
geni_operational_status
: alphanumeric
Change Set O3: Allow unicode values
Many values defined by this API appear to be limited to ASCII characters - both arguments and returns. We would like to support internationalization. Some values in this API (e.g. those defined as URLs) implicitly support unicode. Currently, a well behaved aggregate should be able to handle unicode values in at least some arguments. Similarly, a well behaved client should be able to handle unicode returns.
This change would clarify the support for internationalization in this API, and allow aggregates to specify unicode support. This change would specify:
Aggregates are encouraged to support non-ASCII letters as input. Clients are encouraged to support non-ASCII returns from aggregates. However, this change set does not require that either aggregates or clients support non-ASCII strings, and aggregates should not require clients to accept non-ASCII results where the API does not explicitly require it.
This change would allow an aggregate to explicitly specify that arguments may be unicode, and returns may be unicode if the content demands it. By default, aggregates are expected to use the ASCII only regular expressions that the rest of this API specification uses, and to limit returns to ASCII characters where possible. This change would add an optional return from GetVersion
that allows an aggregate to specify that unicode arguments are acceptable (ASCII strings must still be accepted), and that all returns may be unicode. When the aggregate specifies this option, it shall still attempt to support ASCII inputs to allow clients to operate only in ASCII where possible.
Specifically, this change adds geni_unicode_compliant
to the return from GetVersion
.
- This field is optional.
- Default is
false
. All strings specified in this API are to be treated as ASCII unless otherwise specified, (e.g. the format explicitly references a standard that supports unicode). This includes both arguments and returns. - When
true
, all strings specified in this API may be unicode. In particular, regular expressions that limit to ASCII characters shall be interpreted to include the unicode equivalents. The aggregate will still accept ASCII input. Returns will remain ASCII where the API defines ASCII constants or content allows it.
Older Proposals
Older proposals, withdrawn, superseded, or postponed:
- Change Set C: On hold (waiting for a revised proposal). Add the ability to UpdateSlivers to immediately modify your reservation
- Change Set E: Tickets: On hold (waiting for a revised proposal). Add methods using tickets to do negotiated reservations
Change Set F1: Superseded by F3 and F4: Define sliver states, and the state changes that various methods causeChange Set F2: Superseded by F3 and F4: Add a new general ActOnSlivers method allowing AMs to support AM and resource-type specific operationsChange Set H: Superseded by F3: Clarify: A second call to CreateSlivers without an intervening DeleteSlivers is an error.Change Set I4: Superseded by F3 and F4: CreateSlivers optionally does not start resources.- Withdrawn: Change Set J: Support proxy aggregates with 1 new option and 1 new GetVersion entry
- Postponed: Change Set L: Standardize slice credential privileges
Unspecified items
- UpdateSlivers: Update a reservation or sliver in place, without risking losing resources
- Publish credential schema
- Define error codes returned by new methods, conditions
Changes Not Included
RSpec changes resulting in GENI v4 RSpecs
- Support unbound manifests
- Make manifest an extension of Request, so you can readily edit & resubmit a manifest
- Make configuration information in request and manifest optional, so it can be supplied/returned separately
- Fully implement the compute ontology from Ilia
- Ilia's other requests (Openflow related information)
- Document process for updates per my dev list email
- Be consistent: ref vs idref vs href
- Include AM name/URL in RSpecs? Experimenter who allocated it URN?
- Incorporate stitching extension as part of the 'base' RSpec
Misc
- Allow Shutdown on a single sliver or a list of slivers
- Add
geni_am_info
block to GetVersion return (name, id, url, location, description, is_proxy, proxy: {(a geni_am_info block)}, proxy_for[] (list of geni_am_info blocks)) - Allow the update methods to take a generic rspec argument, allowing AMs to accept full or diff RSpecs
- Tickets
- Remove requestor certificate?
- Support brokers: Make ticket methods return multiple tickets. Define tickets as optionally diffs (additive). Make RedeemTicket and UpdateTicket take a list of tickets. Tickets are delegatable via signing, but the delegated ticket must be for a strict subset of the resources in the original.
- Drop ticket struct, not a signed document. Just reference by ID
- Support message passing
- Add sendMsg (and getMsgs?) methods that take a signed document, allowing freely passing messages instead of XMLRPC?
Stitching
AMs must support the stitching extension where Layer 2 connections are available:
- including in ads, requests, and manifests.
- Advertise available VLANs, attempt to honor requested VLANs, reserve VLANs with tickets, and report reserved or instantiated VLANs in manifests
- Use schema http://hpn.east.isi.edu/rspec/ext/stitch/0.1/stitch-schema.xsd
Update stitching schema per changes here: https://geni.maxgigapop.net/twiki/bin/view/GENI/NetworkStitchingGeniApiAndRspec
Attachments (1)
- update-state.png (47.2 KB) - added by 12 years ago.
Download all attachments as: .zip