Opened 12 years ago
Closed 12 years ago
#109 closed (fixed)
gmoc.py serializes the slice creator and primary_contact as e-mail addresses rather than URNs
Reported by: | chaos@bbn.com | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | gmoc.py data submission debugging |
Component: | Clients | Version: | |
Keywords: | v0.6.4 | Cc: | |
Dependencies: |
Description
Slice submission using gmoc.py is serialized as:
<slice created="1349214385" creator="chaos@bbn.com" expires="1349217985" operator="urn:publicid:IDN+gmoc.geni.net+organization+BBN" primary_contact="chaos@bbn.com" urn="urn:publicid:IDN+pgeni1.gpolab.bbn.com+slice+ecgtest" uuid="b3ec2d36-0cb0-11e2-adf1-000c29b09582" />
Once 105 is fixed, URNs will be the right way to uniquely identify people, and we will need to encode slice creator and contact as URNs rather than as e-mail addresses.
Change History (3)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Okay, so now we have:
<slice created="1349235340" creator="urn:publicid:IDN+pgeni1.gpolab.bbn.com+user+chaos" expires="1349238940" operator="urn:publicid:IDN+gmoc.geni.net+organization+BBN" primary_contact="chaos@bbn.com" urn="urn:publicid:IDN+pgeni1.gpolab.bbn.com+slice+ecgtest10" uuid="7e67d993-0ce1-11e2-adf1-000c29b09582" />
So that looks better. However, the most recent slice submissions to the database are:
(2670,'urn:publicid:IDN+pgeni1.gpolab.bbn.com+slice+ecgtest10',1349209473,'f11febbe-0cc7-11e2-adf1-000c29b09582',1349224365,1349227965,''), (2671,'urn:publicid:IDN+pgeni1.gpolab.bbn.com+slice+ecgtest10',1349214938,'d894c5aa-0cd3-11e2-adf1-000c29b09582',1349229478,1349233078,'');
That last field, which should be the primary_contact, is ''
, and should be chaos@bbn.com
the way the XML is submitting it.
comment:3 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is working now for new slices, see e.g. http://codepad.org/sLdjkwxi and http://codepad.org/exncI1Oe.
I'm not 100% able to verify that slice->creator is being set correctly, due to 115, 116, and my own laziness. But i have no reason to believe it's not being set correctly, and the XML is correct now. So i'm declaring this fixed.
Actually, primaryContact is an arbitrary email not a Contact object.