Opened 9 years ago

Last modified 9 years ago

#152 new

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

Reported by: lnevers@bbn.com Owned by: somebody
Priority: major Milestone:
Component: AM Version: SPIRAL5
Keywords: Cc:
Dependencies:

Description

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: ============================================================

Change History (27)

comment:1 Changed 9 years ago by ibaldin@renci.org

Did the rspec have the 'expires' attribute set?

comment:2 Changed 9 years ago by lnevers@bbn.com

The RSpec did not specify expires attributes.

comment:3 Changed 9 years ago by ibaldin@renci.org

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

comment:4 in reply to:  3 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by ahelsing@bbn.com

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

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by 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).

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by 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?

comment:11 Changed 9 years ago by 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.

comment:12 Changed 9 years ago by ibaldin@renci.org

Make that tic 59

comment:13 Changed 9 years ago by 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.

comment:14 Changed 9 years ago by ibaldin@renci.org

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

comment:15 Changed 9 years ago by ibaldin@renci.org

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

comment:16 Changed 9 years ago by 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.

comment:17 in reply to:  15 Changed 9 years ago by 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).

comment:18 Changed 9 years ago by 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.

comment:19 Changed 9 years ago by 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
    
  1. 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)
  1. 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.
    
  1. 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" 
  1. 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.
    
  1. 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.

  1. 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 
    
  1. Verify the use of expired slice credentials from item 7. To be captured upon slice expiration.

comment:20 in reply to:  19 Changed 9 years ago by 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.

comment:21 Changed 9 years ago by 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.

comment:22 in reply to:  21 Changed 9 years ago by 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.

comment:23 Changed 9 years ago by 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

comment:24 Changed 9 years ago by 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.

comment:25 Changed 9 years ago by 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.

comment:26 Changed 9 years ago by 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

comment:27 Changed 9 years ago by ibaldin@renci.org

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

Note: See TracTickets for help on using tickets.