create with SLICE has undesirable expiration semantics

[nbastin]

...at least to me.. :-)

If I pass an expiration date to create for SLICE, and that expiration date is later than apparently some internally-set expiration maximum in the CH (which we can't find out until we try to make one, I think), my date is ignored and the slice is created with a different date:

>>> context.cf.createSlice(context, "scratch-2", exp=datetime.datetime.now() + datetime.timedelta(days=300))                                                                                        
>>> PP(_)
{'SLICE_CREATION': '2016-02-25T16:29:03Z',
 'SLICE_DESCRIPTION': '',
 'SLICE_EXPIRATION': '2016-08-28T16:29:03Z',
 'SLICE_EXPIRED': False,
 'SLICE_NAME': 'scratch-2',
 'SLICE_PROJECT_URN': 'urn:publicid:IDN+ch.geni.net+project+bss-sw-test',
 'SLICE_UID': '140fb97c-dee1-42b4-82aa-a7138d720672',
 'SLICE_URN': 'urn:publicid:IDN+ch.geni.net:bss-sw-test+slice+scratch-2',
 '_GENI_PROJECT_UID': '5f5fbc4a-f5e4-4688-8901-07109f60f151',
 '_GENI_SLICE_EMAIL': None,
 '_GENI_SLICE_OWNER': '8a447f06-8bd5-4f32-8fd6-1a3528e7fa37'}

I would expect this request to fail, as it cannot be satisfied.

[tcmitchell]

The maximum slice expiration is currently set to 185 days.

Instead of limiting slice expiration the clearinghouse could return an error indicating that the expiration date exceeds either the project expiration or the max expiration. That error message could also note the actual time that was exceeded so that the user could try again with an expiration that falls within the appropriate range. That would be in the create_slice method in SAv1PersistentImplementation.py.

• Project expiration is handled at https://github.com/GENI-NSF/geni-ch/blob/v2.9/plugins/sarm/SAv1PersistentImplementation.py#L551
• Max expiration is handled at https://github.com/GENI-NSF/geni-ch/blob/v2.9/plugins/sarm/SAv1PersistentImplementation.py#L560
• Both could be handled similarly to expirations in the past instead.

[nbastin]

Right, an error with metadata describing the max would be best (so a client could automatically back-off without human intervention if they wanted, thus regaining the same behaviour we have now just in client control). Given that you can't delete slices, any kind of "success" that isn't exactly what the user asks for leaves them in a possibly bad spot with a created slice that doesn't match their parameters.

[tcmitchell]

We could probably also include the max slice expiration value in the get_version response so clients don't need to make a create_slice call in order to discover the value.

[tcmitchell]

A new key _GENI_MAX_SLICE_EXPIRATION_DAYS has been added to the Slice Authority's response to get_version. The value of this key is the maximum number of days that can be requested in create_slice and renew_slice.