when a Sliver object is downloaded, the associated slice is not populated

[chaos@bbn.com]

This sliver download code:

print self.slivertype
self.obj = self.unit.client_obj.load(gmoc.Sliver(self.slivertype))
print self.obj.slice

yields:

urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82
None

The sliver in question was submitted as:

<sliver approved="true" created="1342549645" creator="urn:publicid:IDN+gmoc.geni.net+contact+gpo-infra-rothe008_geni.net" expires="1362114000" local_name="urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82" slice_urn="urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr" slice_uuid="ff6d2b12-f10e-11e0-bf86-000c29f89f7b" state="Up" uuid="b72b0a06-beb9-4be2-94ba-cfbd8654ad82">
...

so it should have a mapping to slice:

urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr

and that mapping should be downloaded.

[chaos@bbn.com]

Hmm... so, now this code (modified just to print the slice id to clean things up):

slivertype = 'urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82'
print slivertype
sliver_obj = self.client_obj.load(gmoc.Sliver(slivertype))
print sliver_obj.slice.id

yields:

urn:publicid:IDN+rothe008sa.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82
urn:publicid:IDN+rothe005sa.gpolab.bbn.com+slice+chaos-montreve-macaddr

That ain't right --- that's a mapping between a rothe008 sliver and a rothe005 slice. Those should never have been submitted together. Hmm.

[chaos@bbn.com]

I did a clean test with config_009 (identical to 008 with the tags changed), and get:

urn:publicid:IDN+rothe009sa.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82
urn:publicid:IDN+rothe005sa.gpolab.bbn.com+slice+chaos-montreve-macaddr

Dan showed me that the mapping in the database is this mapping which is being returned to me.

So, basically:

• There is a newly-discovered upload problem in which some UUID is quietly colliding in a problematic way (we assume). My money is on slice UUID, but it could be slice or sliver.
• This problem, in which slivers weren't mapped to slices, is solved.