Opened 10 years ago

Closed 9 years ago

#59 closed (fixed)

renewing a sliver does not change "orca_expires"

Reported by: lnevers@bbn.com Owned by: somebody
Priority: critical Milestone: EG-EXP-5
Component: Experiment Version: SPIRAL4
Keywords: sliver status Cc:
Dependencies:

Description

Changed the expiration for a sliver to July 4th, the command did not report any error, but subsequent sliverstatus still shows the original expiration date for orca_expires. Did the renew take effect?

Following are the commands issued:

$ omni.py -a exobbn renewsliver  EG-EXP-5-scenario1  2012-07-04
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 expires on 2012-07-04 00:00:00 UTC
INFO:omni:Renewing Sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 until 2012-07-04 00:00:00+00:00 (UTC)
INFO:omni:Substituting AM nickname exobbn with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 at unspecified_AM_URN (https://bbn-hn.exogeni.net:11443/orca/xmlrpc) until 2012-07-04T00:00:00+00:00 (UTC)
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed renewsliver:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True

  Args: renewsliver EG-EXP-5-scenario1 2012-07-04

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 expires on 2012-07-04 00:00:00 UTC
Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 at unspecified_AM_URN (https://bbn-hn.exogeni.net:11443/orca/xmlrpc) until 2012-07-04T00:00:00+00:00 (UTC) 
INFO:omni: ============================================================
lnevers@arendia:~/gcf-1.6.2$ 
lnevers@arendia:~/gcf-1.6.2$ 
lnevers@arendia:~/gcf-1.6.2$ omni.py -a exobbn sliverstatus  EG-EXP-5-scenario1 
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 expires on 2012-07-04 00:00:00 UTC
INFO:omni:Substituting AM nickname exobbn 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+EG-EXP-5-scenario1:
INFO:omni:Sliver status for Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 at AM URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc
INFO:omni:{'geni_resources': [{'geni_status': 'Active',
                     'geni_urn': 'urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+e76465a0-0369-4392-802e-2d2bf43ffe78#VM-0',
                     'orca_expires': 'Sat Jun 30 16:10:07 UTC 2012'},
                    {'geni_status': 'Active',
                     'geni_urn': 'urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+e76465a0-0369-4392-802e-2d2bf43ffe78#VM',
                     'orca_expires': 'Sat Jun 30 16:10:07 UTC 2012'}],
 'geni_status': 'ready',
 'geni_urn': 'urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1'}
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed sliverstatus:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True

  Args: sliverstatus EG-EXP-5-scenario1

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-5-scenario1 expires on 2012-07-04 00:00:00 UTC
Returned status of slivers on 1 of 1 possible aggregates. 
INFO:omni: ============================================================

Change History (32)

comment:1 Changed 10 years ago by jbs@bbn.com

One follow-up to this: It doesn't seem to happen immediately, but orca_expires does seem to get updated eventually, in that slivers that I renewed, and then checked sliverstatus soon afterwards, still had the old expiration date; but a day or two later, when I checked again, they had the new date.

comment:2 Changed 10 years ago by jbs@bbn.com

It looks like it happens when the original expiration date comes. I had used renewsliver to renew my jbs15 sliver at RENCI ExoGENI ORCA until Oct 15th, and sliverstatus still showed the old date, until the old date arrived.

I ran a while loop, like this:

while true ; do date ; omni -a https://rci-hn.exogeni.net:11443/orca/xmlrpc sliverstatus jbs15 2>&1 | grep _expires ; sleep 60 ; done | tee expiration-test.txt

It eventually said:

Fri Jul  6 15:47:31 EDT 2012
                     'orca_expires': 'Fri Jul 06 19:49:54 UTC 2012'}],
Fri Jul  6 15:48:33 EDT 2012
                     'orca_expires': 'Fri Jul 06 19:49:54 UTC 2012'}],
Fri Jul  6 15:49:35 EDT 2012
                     'orca_expires': 'Fri Jul 06 19:49:54 UTC 2012'}],
Fri Jul  6 15:50:37 EDT 2012
                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],
Fri Jul  6 15:51:40 EDT 2012
                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],
Fri Jul  6 15:52:43 EDT 2012
                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],

i.e. when the sliver was going to expire, the changed expiration date started showing up in sliverstatus.

I tried changing it to Oct 14th, just to see what would happen, but it didn't show up immediately (so I changed it back).

comment:3 Changed 10 years ago by jbs@bbn.com

Incidentally, this is probably not surprising, but renewing the sliver also doesn't change the 'expiration_time' value in the manifest rspec (e.g. with listresources).

comment:4 Changed 10 years ago by jbs@bbn.com

This seems to still be an issue. Any ETA for a fix? It makes it hard to tell when your slivers are going to expire, and frustrating when they vanish unexpectedly.

comment:5 Changed 10 years ago by jbs@bbn.com

I'm not actually 100% sure that this is still behaving the same way -- both Tim and I recently thought that we'd renewed slivers which then vanished. Let's test! I've done

omni -a https://rci-hn.exogeni.net:11443/orca/xmlrpc renewsliver jbs15 2012-10-15 19:00 UTC
omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc renewsliver jbs15 2012-10-15 19:00 UTC
omni -a https://rci-hn.exogeni.net:11443/orca/xmlrpc renewsliver jbs16 2012-10-15 19:00 UTC
omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc renewsliver jbs16 2012-10-15 19:00 UTC

And gotten back:

INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs15 at unspecified_AM_URN (https://rci-hn.exogeni.net:11443/orca/xmlrpc) until 2012-10-15T19:00:00+00:00 (UTC)
INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs15 at unspecified_AM_URN (https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc) until 2012-10-15T19:00:00+00:00 (UTC)
INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16 at unspecified_AM_URN (https://rci-hn.exogeni.net:11443/orca/xmlrpc) until 2012-10-15T19: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 2012-10-15T19:00:00+00:00 (UTC)

sliverstatus still says:

                     'orca_expires': 'Thu Aug 16 22:01:50 UTC 2012'}],
                     'orca_expires': 'Thu Aug 16 22:01:54 UTC 2012'}],
                     'orca_expires': 'Thu Aug 16 22:01:59 UTC 2012'}],
                     'orca_expires': 'Thu Aug 16 22:02:04 UTC 2012'}],

So let's see what happens after Thursday at 18:00. I predict either: (a) sliverstatus will change to report the new expiration date; (b) the slivers will expire and be deleted.

comment:6 Changed 10 years ago by jbs@bbn.com

Huh, one other tidbit: http://bbn-hn.exogeni.net:11080/orca/secure/user/reservations-active-view.vm now says

No      Slice                                                           Type                               Units [R] Units [A]  Start                   End                     Broker          Site            State   
1       urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3       OpenStack Virtual Machine (BBN)         1       1       08/14/2012 22:22        08/15/2012 22:22        bbn-broker      bbn-vm-am       Active
2       urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs15		OpenStack Virtual Machine (BBN)         1       1       08/15/2012 22:01        08/16/2012 22:01        bbn-broker      bbn-vm-am       Extending Ticket
3       urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+jbs16		OpenStack Virtual Machine (BBN)         1       1       08/15/2012 22:02        08/16/2012 22:02        bbn-broker      bbn-vm-am       Extending Ticket

Note that they End tomorrow at around 22:00 UTC, but their State is "Extending Ticket". What's that mean?

comment:7 Changed 10 years ago by jbs@bbn.com

http://bbn-hn.exogeni.net:11080/orca/secure/user/reservations-active-view.vm has the same state this morning as in the previous update (except that EG-EXP-6-exp3 is gone, but that's presumably unrelated). I should be able to check back in at around 18:30 Eastern to see what ends up happening.

comment:8 Changed 10 years ago by lnevers@bbn.com

There are various inconsistencies with ExoGENI BBN sliver EG-EXP-6-exp3:

I renewed it this morning without problem:

INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 expires on 2012-08-22 00:00:00 UTC
INFO:omni:Renewing Sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 until 2012-08-22 00:00:00+00:00 (UTC)
INFO:omni:Substituting AM nickname exobbn with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 at unspecified_AM_URN (https://bbn-hn.exogeni.net:11443/orca/xmlrpc) until 2012-08-22T00:00:00+00:00 (UTC)
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed renewsliver:

  Options as run:
		aggregate: exobbn
		framework: pg
		native: True

  Args: renewsliver EG-EXP-6-exp3 2012-08-22

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 expires on 2012-08-22 00:00:00 UTC
Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 at unspecified_AM_URN (https://bbn-hn.exogeni.net:11443/orca/xmlrpc) until 2012-08-22T00:00:00+00:00 (UTC)

But according to sliver status it is gone:

$ ./src/omni.py sliverstatus -a exobbn EG-EXP-6-exp3           INFO:omni:Loading config file /home/lnevers2/.gcf/omni_config
INFO:omni:Using control framework pg
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 expires on 2012-08-22 00:00:00 UTC
INFO:omni:Substituting AM nickname exobbn 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+EG-EXP-6-exp3:
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed sliverstatus:

  Options as run:
		aggregate: exobbn
		framework: pg
		native: True

  Args: sliverstatus EG-EXP-6-exp3

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3 expires on 2012-08-22 00:00:00 UTC

Failed to get SliverStatus on EG-EXP-6-exp3 at AM https://bbn-hn.exogeni.net:11443/orca/xmlrpc: ERROR: There are no reservations in the slice with sliceId = urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3
Returned status of slivers on 0 of 1 possible aggregates. 
INFO:omni: ============================================================

But a listresources still shows that is active:

$ ./src/omni.py listresources -a exobbn EG-EXP-6-exp3 
INFO:omni:Loading config file /home/lnevers2/.gcf/omni_config
INFO:omni:Using control framework pg
INFO:omni:Gathering resources reserved for slice EG-EXP-6-exp3.
INFO:omni:Substituting AM nickname exobbn with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Listed resources on 1 out of 1 possible aggregates.
INFO:omni:<?xml version="1.0" ?>
INFO:omni:<!-- Resources for:
	Slice: EG-EXP-6-exp3
	at AM:
	URN: unspecified_AM_URN
	URL: https://bbn-hn.exogeni.net:11443/orca/xmlrpc
 -->
INFO:omni:<rspec type="manifest" xmlns="http://www.geni.net/resources/rspec/3" xmlns:ns2="http://hpn.east.isi.edu/rspec/ext/stitch/0.1/" xmlns:ns3="http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/slice-info/1" xmlns:ns4="http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/sliver-info/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geni.net/resources/rspec/3 http://www.geni.net/resources/rspec/3/manifest.xsd http://hpn.east.isi.edu/rspec/ext/stitch/0.1/ http://hpn.east.isi.edu/rspec/ext/stitch/0.1/stitch-schema.xsd http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/slice-info/1 http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/slice-info/1/slice_info.xsd?format=raw http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/sliver-info/1 http://groups.geni.net/exogeni/attachment/wiki/RspecExtensions/sliver-info/1/sliver_info.xsd?format=raw">  
      <node client_id="VM" component_id="urn:publicid:IDN+exogeni.net:bbnvmsite+node+orca-vm-cloud" component_manager_id="urn:publicid:IDN+exogeni.net:bbnvmsite+authority+am" component_name="orca-vm-cloud" exclusive="true" sliver_id="urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+a185b84a-884d-4746-8fa8-c1c32e5f3674#VM">    
            <sliver_type name="m1.small">      
                  <disk_image name="http://geni-images.renci.org/images/standard/debian/debian-squeeze-amd64-neuca-2g.zfilesystem.sparse.v0.2.xml" version="397c431cb9249e1f361484b08674bc3381455bb9"/>      
            </sliver_type>    
            <services>      
                  <login authentication="ssh-keys" hostname="192.1.242.9" port="22" username="root"/>      
            </services>    
            <interface client_id="VM:if0">      
                  <ip address="10.42.11.198" netmask="255.255.0.0" type="ipv4"/>      
            </interface>    
            <ns4:geni_sliver_info creation_time="2012-08-14T18:22:26.060-04:00" creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers2" expiration_time="2012-08-15T18:22:26.060-04:00" start_time="2012-08-14T18:22:26.060-04:00" state="Active"/>    
      </node>  
      <link client_id="lan0" sliver_id="urn:publicid:IDN+exogeni.net:bbnvmsite+sliver+a185b84a-884d-4746-8fa8-c1c32e5f3674#lan0" vlantag="1750">    
            <interface_ref client_id="VM:if0"/>    
            <ns4:geni_sliver_info creation_time="2012-08-14T18:22:26.060-04:00" creator_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers2" expiration_time="2012-08-15T18:22:26.060-04:00" start_time="2012-08-14T18:22:26.060-04:00"/>    
      </link>  
      <ns3:geni_slice_info state="unknown" urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+EG-EXP-6-exp3" uuid="690de9ca-c66d-4474-9819-5930300820e9"/>  
</rspec>
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed listresources:

  Options as run:
		aggregate: exobbn
		framework: pg
		native: True

  Args: listresources EG-EXP-6-exp3

  Result Summary: Retrieved resources for slice EG-EXP-6-exp3 from 1 aggregates.
Wrote rspecs from 1 aggregates. 

Attempts to login to the assigned host fail:

lnevers2@arendia:~/gcf-1.6.2$ ssh root@192.1.242.9
ssh: connect to host 192.1.242.9 port 22: No route to host

comment:9 Changed 10 years ago by jbs@bbn.com

Luisa, I suspect that your last update is actually about the problem in ticket 60, not this one.

comment:10 Changed 10 years ago by lnevers@bbn.com

Right Josh, Sorry. Please disregard comment 8 in this ticket. Adding content from comment 8 to ticket 60. Sorry about the confusion. :-)

comment:11 Changed 10 years ago by jbs@bbn.com

Hey, it's after 18:00... And three of my slivers appear to gotten new expiration dates:

                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],
                     'orca_expires': 'Thu Aug 16 22:01:54 UTC 2012'}],
                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],
                     'orca_expires': 'Mon Oct 15 19:00:00 UTC 2012'}],

...but one hasn't, that's jbs15 at BBN. And even more slightly weird, that expiration date is in the past.

http://bbn-hn.exogeni.net:11080/orca/secure/user/reservations-active-view.vm still includes jbs16, but now does not include jbs15. jbs16 State is "Active", with an End time of "10/15/2012 19:00".

http://bbn-hn.exogeni.net:11080/orca/secure/user/slice-view.vm?&actor=bbn-sm&slice=7f7814fb-cae5-4024-ba38-ae8e48bdf41f shows jbs15, and says that its State is "Closing", so perhaps it's in the process of being (slowly) deleted?

Bleah.

comment:12 Changed 10 years ago by jbs@bbn.com

Priority: majorcritical

Bottom line is:

  • For three of my slivers, renewsliver said it succeeded, but sliverstatus didn't reflect that, but when the original expiration date came, it was extended.
  • For one of my slivers, renewsliver said it succeeded, but sliverstatus didn't reflect that, and when the original expiration date came, it was deleted. (Or is still in the process of being deleted, apparently.)

The first thing is what this ticket was originally talking about, and is merely annoying -- if an experimenter does a renewsliver, it looks like it didn't work, but it actually did, so at least they won't lose their stuff.

The second thing is much more problematic, because sometimes when an experimenter does a renewsliver, it looks like it didn't work, and it actually didn't, but this is completely indistinguishable from the case when it did actually work, and they won't find out until the expiration time comes, when they'll suddenly lose their stuff.

Is there anything else I (or anyone) can do to help debug this? It's at least critical, if not a blocker; the racks aren't usable if experimenters can't reliably tell whether or when their resources will vanish.

comment:13 Changed 10 years ago by jbs@bbn.com

No one from the ExoGENI side has commented on (or even acknowledged) this critical ticket. Is anyone working on it? Who needs to take the next action here?

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

ACK.

We will take a look at it, but there is a chance this will not get fixed until 4.0 is fully out (two months). Considering the fairly regular maintenance periods we have, I would think the real impact of this issue is rather small.

comment:15 Changed 10 years ago by jbs@bbn.com

Well, the immediate impact is that since we're using an ORCA sliver to test connectivity to the rack, connectivity tests fail every time the sliver expires, which happens every day or two, since the default expiration time is very short.

Is the default expiration time configurable? Setting that to something more like a few weeks (the interval between maintenance periods, say) would mitigate the immediate problem.

comment:16 Changed 10 years ago by ibaldin@renci.org

It is configurable. Currently there is a 2-week limit.

comment:17 Changed 10 years ago by jbs@bbn.com

That's the maximum time you can renew your sliver for, but it's not the default expiration time you get with a new sliver, is it?

I created a new sliver on the BBN rack just now, and got an expiration time of "Fri Aug 24 20:57:45 UTC 2012", i.e. 24 hours from now.

comment:18 Changed 10 years ago by jbs@bbn.com

That's the maximum time you can renew your sliver for

Actually, I'm not sure that's true either, because I've renewed slivers for more than two weeks. (jbs15 at RENCI right now, says "Mon Oct 15 19:00:00 UTC 2012".)

comment:19 Changed 10 years ago by ibaldin@renci.org

NDL-RSpec converter sets time to 24 hours by default.

Two weeks is the maximum time you can ask when you create the slice. We currently don't check after that.

I don't remember if RSpec allows you to specify desired slice lifetime duration. If it doesn't please come up with an extension and I will add it to the converter. ORCA's NDL format lets you specify start/stop times, so when using Flukes you can do it.

comment:20 Changed 10 years ago by jbs@bbn.com

Expedient used to set expiration dates in rspecs, and my recollection is that pretty much everyone thought that was a terrible idea, but I could be wrong. I'll talk to the local rspec experts and see what they think.

Meanwhile:

NDL-RSpec converter sets time to 24 hours by default.

Can that be changed?

comment:21 Changed 10 years ago by ibaldin@renci.org

I suggest we don't add off-the-cuff subjective comments to ticket threads.

Of course the default can be changed, it is software, after-all. My preference would be to have a short default, like we do now, and have an extension for users wanting to specify a longer term. This way if someone wants a long lived slice and says so, we can (a) make sure the resources are available and (b) warn them if their desired lifetime exceeds what we can promise.

It also enables us to properly schedule such demands. We do do long-term scheduling and not having this extension will result in Flukes users having an advantage over omni users because lifetime extension is always a weaker promise, compared to hard scheduling with a deadline.

comment:22 Changed 10 years ago by jbs@bbn.com

My preference would be to have a short default, like we do now, and have an extension for users wanting to specify a longer term.

The way this is currently done, by every other aggregate in GENI, is via the GENI AM API renewsliver call, not via rspecs.

I understand that ORCA won't support renewsliver until 4.0. In the meanwhile, I think that temporarily changing the default value expiration time in the NDL-RSpec converter, until 4.0 is out and this can be done via the GENI AM API, would be a simpler fix than writing a new rspec extension.

comment:23 Changed 10 years ago by ibaldin@renci.org

What would you like the default to be?

Renewsliver is there, it just needs to be debugged. If we can find the time to debug it we will, but the resources are finite, so the hard promise is 4.0.

comment:24 in reply to:  23 Changed 10 years ago by jbs@bbn.com

What would you like the default to be?

Well, it doesn't need to be longer than the gap between maintenance periods; it'd be nice if it could be as long as that gap. I'd suggest three weeks, but if you don't want it to be longer than the Flukes creation maximum, two weeks would still be an improvement.

Renewsliver is there, it just needs to be debugged. If we can find the time to debug it we will, but the resources are finite, so the hard promise is 4.0.

Yep, understood. I just want to find an easy workaround to make things less painful until then.

comment:25 Changed 10 years ago by ibaldin@renci.org

The converter now sets default slice duration to 2 weeks - 1 hour.

comment:26 in reply to:  25 Changed 10 years ago by jbs@bbn.com

Replying to ibaldin@renci.org:

The converter now sets default slice duration to 2 weeks - 1 hour.

I tried it just now, and it looks good -- thanks!

comment:27 Changed 10 years ago by lnevers@bbn.com

Issue exists in the renewsliver implementation that was captured in ticket #108, which was deemed duplicate of this ticket and closed.

comment:28 Changed 10 years ago by lnevers@bbn.com

Renew sliver failure (ticket #108 and and #128) tracked the sliver renewal failure which reports a "no reason given", this still an issue.

Closing ticket #128, missed that this ticket was tracking the problem with renewal failure because content did not match my search.

comment:29 Changed 10 years ago by ibaldin@renci.org

http://groups.geni.net/exogeni/ticket/59#comment:23 still holds

The orca version is still Camano-3.1-extended

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

The fix for this will be deployed at the end of this week across ExoGENI.

HOWEVER:

You have to provide the renewal date in the format "03/06/13 18:00" , as mentioned in http://trac.gpolab.bbn.com/gcf/wiki/OmniOverview#renewsliver

You can't test using the following format "2013-03-06 18:00 UTC". There is some problem in the omni client that garbles the date and sends wrong date. The following won't work.

python26 src/omni.py -c omni_config -a https://unc-hn.unc.ben:11443/orca/xmlrpc renewsliver omniSlice 2013-03-06 18:00 UTC

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

Correction - dates with spaces and forward slashes all should work, you just need to quote the date.

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

Resolution: fixed
Status: newclosed

Checking status for unresolved tickets. Behavior seen in testing shows that renew sliver works and can extend the orca_expires value, but that the initial orca_expires does not map to the slice expiration date, this mismatch is captured in ticket #152. This ticket is addressed and being closed.

Current behavior:

  1. Created slice lnexo assigned expiration -> Expiration 2013-03-27 14:28:10+00:00
  2. Created 2 VM sliver at GPO SM, manifest shows expiration_time="2013-04-09T12:29:43.120Z"
  3. Sliver status, when sliver is ready shows "orca_expires": "Tue Apr 09 12:29:43 UTC 2013"
  4. Renew sliver beyond the initial orca_expires date (2013-04-10)
  5. New date appears in "orca_expires": "Wed Apr 10 00:00:00 UTC 2013"
  6. Also tested different date format (2013/04/11), which also works.
  7. Changing the sliver expiration date to a date earlier than the initial orca_expires does not have any effect.

Note: See TracTickets for help on using tickets.