Opened 11 years ago

Closed 11 years ago

#52 closed (fixed)

ORCA sliver expiration

Reported by: Owned by:
Priority: major Milestone:
Component: AM Version: SPIRAL4
Keywords: Cc:


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?

Change History (11)

comment:1 Changed 11 years ago by

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.


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

comment:2 Changed 11 years ago by

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': ''}],
 'geni_status': 'ready',
 'geni_urn': ''}

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.

comment:3 Changed 11 years ago by

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.

comment:4 Changed 11 years ago by

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.

comment:5 Changed 11 years ago by

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?

comment:6 Changed 11 years ago by

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.

comment:7 Changed 11 years ago by


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.

comment:8 Changed 11 years ago by

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.

comment:9 Changed 11 years ago by

Owner: changed from somebody to
Status: newassigned

OK, I can work on that.

comment:10 Changed 11 years ago by

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

comment:11 Changed 11 years ago by

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.