when two slices have the same UUID, a sliver may be mapped to the wrong one

[chaos@bbn.com]

UUIDs are only unique per UUID-generating entity, not globally. Therefore, two different slice authorities can validly create distinct slices with the same UUID. That has happened in my test data, where we have slices:

URN	UUID
urn:publicid:IDN+rothe005sa.gpolab.bbn.com+slice+chaos-montreve-macaddr	ff6d2b12-f10e-11e0-bf86-000c29f89f7b
urn:publicid:IDN+rothe009sa.gpolab.bbn.com+slice+chaos-montreve-macaddr	ff6d2b12-f10e-11e0-bf86-000c29f89f7b

(This is a test artifact, but should be legal.)

When i submit this data (​http://codepad.org/nlP8JjoI) the sliver

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

becomes associated to the incorrect slice:

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

The mapping is taking only slice UUID into account, and not slice URN. Instead, the algorithm should be:

• If a sliver provides both slice UUID and slice URN, xchange2db3 should look for a slice which matches both URN and UUID (not just UUID)
• If a sliver provides only slice URN, xchange2db3 should pick the most recent slice which matches that URN

[chaos@bbn.com]

Dan fixed this: in newly-submitted dataset rothe010 (identical to rothe009 except for that tag substitution):

    slivertype = 'urn:publicid:IDN+rothe010sa.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

correctly yields:

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