Should remove the workaround for sliver expiration set to two weeks later than slice expiration

[lnevers@bbn.com]

In earlier versions, Orca set the expiration time for a sliver to a date 2 week later than the slice expiration. This was a workaround for the missing renewsliver feature.

Now that the sliver expiration feature is working the expiration extension should be removed.

From an experiment that was just run, the slice expiration is " 2013-03-12 16:07:42":

$ omni.py print_slice_expiration lnexo
INFO:omni:Loading config file /home/lnevers/.gcf/omni_config
INFO:omni:Using control framework pg
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo expires on 2013-03-12 16:07:42 UTC
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed print_slice_expiration:

  Options as run:
		framework: pg

  Args: print_slice_expiration lnexo

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo expires on 2013-03-12 16:07:42 UTC 
INFO:omni: ============================================================

The sliver expiration is later than the slice expiration and is set to "Mar 25 14:08:28 UTC 2013":

$ omni.py sliverstatus -a eg-gpo lnexo             
INFO:omni:Loading config file /home/lnevers/.gcf/omni_config
INFO:omni:Using control framework pg
INFO:omni:Substituting AM nickname eg-gpo with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo expires on 2013-03-12 16:07:42 UTC
INFO:omni:Substituting AM nickname eg-gpo with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Status of Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo:
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo at AM https://bbn-hn.exogeni.net:11443/orca/xmlrpc has overall SliverStatus: ready
INFO:omni:Sliver status for Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo at AM URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc
INFO:omni:{
  "geni_status": "ready", 
  "geni_urn": "urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo", 
  "geni_resources": [
    {
      "orca_expires": "Mon Mar 25 14:08:28 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+54ff8583-5c59-4523-8a34-2e78bb83c5c6#lan0", 
      "geni_error": "", 
      "geni_status": "Active"
    }, 
    {
      "orca_expires": "Mon Mar 25 14:08:28 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+54ff8583-5c59-4523-8a34-2e78bb83c5c6#VM-2", 
      "geni_error": "", 
      "geni_status": "Active"
    }, 
    {
      "orca_expires": "Mon Mar 25 14:08:28 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+54ff8583-5c59-4523-8a34-2e78bb83c5c6#VM-4", 
      "geni_error": "", 
      "geni_status": "Active"
    }, 
    {
      "orca_expires": "Mon Mar 25 14:08:28 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+54ff8583-5c59-4523-8a34-2e78bb83c5c6#VM-3", 
      "geni_error": "", 
      "geni_status": "Active"
    }, 
    {
      "orca_expires": "Mon Mar 25 14:08:28 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+54ff8583-5c59-4523-8a34-2e78bb83c5c6#VM-1", 
      "geni_error": "", 
      "geni_status": "Active"
    }
  ]
}
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed sliverstatus:

  Options as run:
		aggregate: ['eg-gpo']
		framework: pg

  Args: sliverstatus lnexo

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo expires on 2013-03-12 16:07:42 UTC
Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo at AM https://bbn-hn.exogeni.net:11443/orca/xmlrpc has overall SliverStatus: ready.
 Returned status of slivers on 1 of 1 possible aggregates. 
INFO:omni: ============================================================

[ibaldin@renci.org]

Did the rspec have the 'expires' attribute set?

[lnevers@bbn.com]

The RSpec did not specify expires attributes.

[ibaldin@renci.org]

What should be the behavior if 'expires' isn't specified?

[jbs@bbn.com]

Replying to ibaldin@renci.org:

What should be the behavior if 'expires' isn't specified?

My two cents: It should be set to the expiration date of the GENI slice, or the value of the maximum lease time (if that's an ORCA thing). That's what both FOAM and ProtoGENI do, so it'd be great to be in synch with them.

[ahelsing@bbn.com]

The Aggregate gets to pick, as long as it is not beyond the slice expiration.

[ibaldin@renci.org]

The two things above you're seeing is SA telling you the expiration date, which we don't know and the default set by the converter (2 weeks).

We don't look at SA's credential document for expiration date (we can if it is there, but that won't get fixed quickly - we don't have full a parser for SA slice cred document) . It is either specified as 'expires' attribute of the rspec or set to default by NDL-RSpec converter. I can change this default, but it ultimately will not change the behavior.

[ahelsing@bbn.com]

Ah, so that is the issue. You have no code to check that the slice credential being supplied is not expired? If true, that's a separate (important) issue. (That is code that Prateek had in python when he was working on Orca authorization, taken from the PlanetLab? SFA codebase.) Credentials are signed documents that have an expiration date, so yes that date is there.

While some clients supply the 'expires' attribute, not all do - Omni does not (unless the user puts it there).

[ahelsing@bbn.com]

That can't be quite right.

If I try to do createsliver with an expired slice credential, it fails:

code 3: Credendial Exception: javax.security.auth.login.CredentialException: No credential was found with appropriate privileges.

So you must have some code that checks slice expiration.

[ibaldin@renci.org]

I'm looking at Prateek's code. There is expirationDate there, which I assume is one and the same as slice expiration you are talking about. We should be able to pull it out to fill in as default, but not this week.

[jbs@bbn.com]

Here's some more data about the current state of things.

I have a slice that expires on 2013-06-15:

INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 expires on 2013-06-15 23:00:00 UTC

I was able to renew my BBN ExoGENI sliver to a date later than the slice expiration date:

+$ slicename=jbs16
+$ am=https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc
+$ omni -a $am sliverstatus $slicename |& grep _expir
      "orca_expires": "Sat Jun 22 23:00:00 UTC 2013", 

So that seems bad. Also, in the manifest, there's an even more strange expiration date:

+$ omni -a $am listresources $slicename |& grep expir
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 expires on 2013-06-15 23:00:00 UTC
            <ns4:geni_sliver_info creation_time="2013-03-11T16:55:21.056Z" creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+jbs" expiration_time="2014-04-17T05:16:43.056Z" resource_id="bbn-w5:8ccf0580-84a2-4cb4-bde7-8511c851de28" start_time="2013-03-11T16:55:21.056Z" state="Active"/>    
            <ns4:geni_sliver_info creation_time="2013-03-11T16:55:21.056Z" creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+jbs" expiration_time="2014-04-17T05:16:43.056Z" start_time="2013-03-11T16:55:21.056Z"/>    

What's up with that 2014 expiration time?

Most immediately, a check to make sure that the sliver expiration time isn't later than the slice expiration time is, as Aaron said, important. Is that a thing you can do, armed with Prateek's code? Or is that beyond what you'd seen so far?

[ibaldin@renci.org]

We've had issues with what looked like omni garbling the date. See bottom of tic 52.

Yes, we can look at the date in cred document to check and make sure extend doesn't go beyond what SA has authorized.

[ibaldin@renci.org]

Make that tic 59

[ahelsing@bbn.com]

Note that this (Omni garbles dates) appears to be user error - I can't reproduce this if I use quotes. If you have a specific use case that fails, say so.

[ibaldin@renci.org]

I don't know how jbs is running it, which is why I brought this up.

[ibaldin@renci.org]

What is the proper error code to return if renewSliver requests a date past slice expiration?

[jbs@bbn.com]

How I'm running renewsliver? Here's what I did, with the full output:

+$ omni --devmode -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc renewsliver jbs16 "2013-06-22 23:00 UTC"
INFO:omni:Loading config file /home/jbs/.gcf/omni_config
INFO:omni:Using control framework gpolab
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 expires on 2013-06-15 23:00:00 UTC
WARNING:omni:Cannot renew sliver(s) in jbs16 until 2013-06-22 23:00:00 UTC because it is after the slice expiration time 2013-06-15 23:00:00 UTC, but continuing...
INFO:omni:Renewing Sliver jbs16 until 2013-06-22 23:00:00+00:00 (UTC)
INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 at unspecified_AM_URN (https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc) until 2013-06-22T23:00:00+00:00 (UTC)
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed renewsliver:

  Options as run:
                aggregate: ['https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc']
                devmode: True
                framework: gpolab

  Args: renewsliver jbs16 2013-06-22 23:00 UTC

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 expires on 2013-06-15 23:00:00 UTC
Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 at unspecified_AM_URN (https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc) until 2013-06-22T23:00:00+00:00 (UTC)
 
INFO:omni: ============================================================

That all looks as expected (given the bug that ORCA isn't checking the slice credential experiation), and there's nothing obviously garbled or saying "2014" in there.

[ahelsing@bbn.com]

Replying to ibaldin@renci.org:

What is the proper error code to return if renewSliver requests a date past slice expiration?

​http://groups.geni.net/geni/wiki/GAPI_AM_API_V2_DETAILS#RenewSliverreturncodes

BADARGS (1) if the slice is not expired but the date is too far in the future (past slice expiration). EXPIRED (15) if the slice is expired (or your existing error about no valid credential found).

[ibaldin@renci.org]

OK, so the code to

1) Take slice expiration date if present in cred document and use it as end time for the slice

2) Check the slice expiration date prior to extend

are both in the trunk, but not tested. We'll have to test and deploy some time after the GEC.

[lnevers@bbn.com]

Using version "ORCA Dungeness: v.4.0-SNAPSHOT.build-5468" on the NICTA rack was able to partially verify planned scenarios:

1. Requesting a renew_sliver past slice expiration generates expected error:

   ERROR:omni:Cannot renew sliver(s) in lnexo until 2013-05-31 13:12:54 UTC because 
   it is after the slice expiration time 2013-05-30 00:00:00 UTC
   

2. Verified handling of expired user credentials generate in an error, used omni devmode

to force the expired credentials to be passed on to the NICTA aggregate:

Result Summary: Failed to renew sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo 
on unspecified_AM_URN (https://nicta-hn.exogeni.net:11443/orca/xmlrpc) (got result 'None'). 
Unknown SSL error [Errno 8] _ssl.c:480: EOF occurred in violation of protocol (missing result)

3. Verified handling of non-existing slice credentials (omni devmode):

   Result Summary: Failed to renew sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo2 on 
   unspecified_AM_URN (https://nicta-hn.exogeni.net:11443/orca/xmlrpc) (got result 'None'). 
   Error from Aggregate: code 3: Credendial Exception: javax.security.auth.login.CredentialException: 
   No credential was found with appropriate privileges or valid dates.
   

4. Verified that the initial sliver expiration time from createsliver:

     Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+expire1 expires on 2013-05-29 14:42:44 UTC 
   

Shows up in the sliver manifest:

expiration_time="2013-05-29T10:42:44.000-04:00" 

5. Verified that sliver expiration prior to initial slice expiration is reported as not valid:

   Failed to renew sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+expire1 on 
   unspecified_AM_URN (https://nicta-hn.exogeni.net:11443/orca/xmlrpc) (got result 'None'). 
   Error from Aggregate: code 1: renewSlice(): renewal term shorter than original reservation 
   end is not valid.
   

6. Verified that in a scenario where both the slice and sliver expiration date are extended, it

is possible to shorten the sliver expiration date to a date earlier than the slice expiration.

7. Overnight test. Waiting to verify sliver expiration for these two slivers at NICTA:

   Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+expire1 expires on 2013-05-29 14:42:45 UTC 
   Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo expires on 2013-05-29 13:13:54 UTC 
   

8. Verify the use of expired slice credentials from item 7. To be captured upon slice expiration.

[lnevers@bbn.com]

Replying to lnevers@bbn.com:

1. Requesting a renew_sliver past slice expiration generates expected error:

   ERROR:omni:Cannot renew sliver(s) in lnexo until 2013-05-31 13:12:54 UTC because 
   it is after the slice expiration time 2013-05-30 00:00:00 UTC
   

Accidentally captured the wrong output. For test 1, the actual verification was run with the omni devmode option and the results showed:

Failed to renew sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexo on 
unspecified_AM_URN (https://nicta-hn.exogeni.net:11443/orca/xmlrpc) (got result 'None'). 
Error from Aggregate: code 1: Requested new end date is after slice expiration or exceeds system default.

The above output is as expected.

[lnevers@bbn.com]

Using 'ORCA Dungeness: v.4.0-SNAPSHOT.build-5495' on the GPO rack, verified all the sliver expiration scenario verified on nicta last week, results are the same.

Leaving one sliver to expire overnight, will update with results.

[lnevers@bbn.com]

Replying to lnevers@bbn.com:

Leaving one sliver to expire overnight, will update with results.

The sliver that was left running overnight to expire at the expiration time of "Wed Jun 05 16:46:00 UTC 2013" did not expire. It is now "June 05 17:58:00 UTC 2013" or "13:58:00 EDT" and the sliver is still active according to sliver status:

INFO:omni:Sliver status for Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires at AM URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc
INFO:omni:{
  "geni_status": "ready", 
  "geni_urn": "urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires", 
  "geni_resources": [
    {
      "orca_expires": "Wed Jun 05 16:46:00 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net+sliver+7b565849-6a72-4b25-9ecd-c87150b69689:geni2", 
      "geni_error": "", 
      "geni_status": "ready"
    }, 
    {
      "orca_expires": "Wed Jun 05 16:46:00 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net+sliver+7b565849-6a72-4b25-9ecd-c87150b69689:geni1", 
      "geni_error": "", 
      "geni_status": "ready"
    }, 
    {
      "orca_expires": "Wed Jun 05 16:46:00 UTC 2013", 
      "geni_urn": "urn:publicid:IDN+exogeni.net+sliver+7b565849-6a72-4b25-9ecd-c87150b69689:center", 
      "geni_error": "", 
      "geni_status": "ready"
    }
  ]
}
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed sliverstatus:

  Options as run:
		aggregate: ['eg-gpo']
		framework: pg

  Args: sliverstatus lnexpires

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires expires on 2013-06-30 00:00:00 UTC
Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires at AM https://bbn-hn.exogeni.net:11443/orca/xmlrpc has overall SliverStatus: ready.

[ibaldin@renci.org]

Those reservations appear to have been extended until June 13. That's why they are still active

4aa565df-9778-4c83-8744-b04fa58bda8f bbn-sm

1 bbnvmsite.vm [ active, nascent] Notices: Reservation 4aa565df-9778-4c83-8744-b04fa58bda8f (Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires) is in state [Active,None] Start: Tue Jun 04 11:46:11 EDT 2013 End:Thu Jun 13 20:00:00 EDT 2013

ba507669-c239-4ac8-af57-5051c1266d65 bbn-sm

1 bbnvmsite.vm [ active, nascent] Notices: Reservation ba507669-c239-4ac8-af57-5051c1266d65 (Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires) is in state [Active,None] Start: Tue Jun 04 11:46:11 EDT 2013 End:Thu Jun 13 20:00:00 EDT 2013

d432e645-e778-4f59-ae49-387fb343ed6a bbn-sm

1 bbnvmsite.vlan [ active, nascent] Notices: Reservation d432e645-e778-4f59-ae49-387fb343ed6a (Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnexpires) is in state [Active,None] Start: Tue Jun 04 11:46:11 EDT 2013 End:Thu Jun 13 20:00:00 EDT 2013

[lnevers@bbn.com]

I had extended the sliver to June 13th and then set it back to the original expiration time of June 5th. The renewsliver command that set the expiration back to June 5th was successful and it modified the "orca_expires" time to June 5th. Both sliver status and the the sliver manifest show the June 5th expiration:

<ns4:geni_sliver_info creation_time="2013-06-04T15:46:12.000Z" 
creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers" 
expiration_time="2013-06-05T16:46:00.000Z" resource_id="bbn-w4:184fd2c2-cb8e-4abc-
b78c-50b454f67519" start_time="2013-06-04T15:46:12.000Z" state="ready"/>  
  
<ns4:geni_sliver_info creation_time="2013-06-04T15:46:12.000Z" 
creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers"
 expiration_time="2013-06-05T16:46:00.000Z" resource_id="bbn-w1:6bc2f31d-0f17-4d5c-
bfea-2c06bce781e0" start_time="2013-06-04T15:46:12.000Z" state="ready"/> 
   
<ns4:geni_sliver_info creation_time="2013-06-04T15:46:12.000Z" 
creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers" 
expiration_time="2013-06-05T16:46:00.000Z" start_time="2013-06-04T15:46:12.000Z" 
state="ready"/> 

As an experimenter, I am not able to see the "actual" Reservation End Time of June 13th.

[ibaldin@renci.org]

So there are two things here

1. Yes, for some reason it is not reporting the correct time.
2. Setting time back on reservation is actually not allowed (never will be).

So we need to fix these two things. Otherwise, the system is behaving correctly.

[ibaldin@renci.org]

I mean we need to fix

a) So setting time back results in an error

and

b) That sliverstatus reports the actual reservation time

[ibaldin@renci.org]

Fixed in 5508. Will be deployed at next available opportunity.