ORCA sliver expiration

[jbs@bbn.com]

Is there a way for an experimenter to find out their ORCA sliver's expiration date? Other aggregates often put this information in sliverstatus, e.g. a foam_expires or pg_expires field.

Does ORCA notify the experimenter when their sliver is going to expire soon?

[tmitchel@bbn.com]

As far as I know there is no affordance for returning expiration in AM API v2 SliverStatus, but AM API v3 does specify a "geni_expires" key as part of the return from "Status". If the data is available, it could be stored with this key in AM API v2 SliverStatus.

See:

• ​http://groups.geni.net/geni/wiki/GAPI_AM_API_V3#Status
• ​http://groups.geni.net/geni/wiki/GAPI_AM_API_V3/CommonConcepts#Expirationtimes
• ​http://groups.geni.net/geni/wiki/GAPI_AM_API_V3/CommonConcepts#datetimedatatype

I don't see any expiration in GENI RSpec v3, but it was a fairly cursory search.

[jbs@bbn.com]

Hmm so here's what FOAM 0.6 currently does:

 INFO:omni:{'foam_expires': '2012-10-15 19:00:00',
 'foam_status': 'Approved',
 'geni_resources': [{'geni_error': '',
                     'geni_status': 'ready',
                     'geni_urn': 'urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs15:e55b3f80-4955-4d8a-844c-4a779a794419'}],
 'geni_status': 'ready',
 'geni_urn': 'urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs15:e55b3f80-4955-4d8a-844c-4a779a794419'}

That is, there's a foam_expires (and foam_status) field there; those presumably aren't defined by the GENI spec, but are they *allowed* by it, as optional AM-defined fields?

That's what I had in mind as a quick and easy way to do this, with an orca_expires field or something.

[ahelsing@bbn.com]

Indeed, the AM API allows arbitrary other fields in sliver status. For an AM API v1 or v2 implementation, I 2nd Josh's suggestion that you add an orca_expires field.

Note that in AM API v3, the expiration field is more explicitly returned as part of the API.

[ibaldin@renci.org]

My preference would be to use a schema someone else has defined and/or wait until it becomes part of core RSpec. Orca is not doing anything different here from other CFs, I don't think, so having an Orca-specific field seems like a wrong approach.

[jbs@bbn.com]

That seems fine (to me) from an API compliance point of view; it's only problematic from a user interface point of view, because there isn't an easy way for experimenters to find out when their slivers are going to expire.

I'd had another question in here: Does ORCA notify the experimenter when their sliver is going to expire soon?

[ibaldin@renci.org]

Orca does not have any email gateway capability, which is I think what you're asking about. Again, I would suggest drafting an extension that would work for all or most control frameworks and we will be able to include this information in there.

[ahelsing@bbn.com]

Ilia-

What other CFs do is in fact to have per-CF fields in the return from sliver status, when implementing AM API v1 or v2. v3 standardizes this return. So by including the sliver expiration time in your return from sliver status, you will indeed be doing what other aggregates do.

And you will be that little bit closer to being able to implement AM API v3.

[ahelsing@bbn.com]

One other comment: you said 'extension', but I think an RSpec extension is the wrong place to put this information. AM API v3 says it is a field in the return from several methods. Use that.

[ibaldin@renci.org]

OK, I can work on that.

[ibaldin@renci.org]

orca_expires should be returned as part of list resources as well as, I believe, the sliver_info extension added to the manifests.

[jbs@bbn.com]

orca_expires now shows up in sliverstatus; in listresources, there's an 'expiration_time' parameter in the ns4:geni_sliver_info elements. Unless that parameter should be orca_expires too (I have no idea and will cheerfully agree with whatever anyone else thinks), I think that's it for this one.