Opened 12 years ago
Closed 12 years ago
#101 closed (fixed)
foam5.gpolab.bbn.com sliver data is not being submitted to the database
Reported by: | chaos@bbn.com | Owned by: | chaos@bbn.com |
---|---|---|---|
Priority: | major | Milestone: | gmoc.py data submission debugging |
Component: | Database | Version: | |
Keywords: | Cc: | ||
Dependencies: |
Description
The following XML is successfully submitted from tau-verde (foam5.gpolab.bbn.com) to gmoc-db2:
<?xml version="1.0" ?> <gmoc_topology time="1349133955" version="4"> <pop name="urn:publicid:IDN+gmoc.geni.net+pop+gpolab"/> <aggregate name="foam5.gpolab.bbn.com:3626" organization="urn:publicid:IDN+gmoc.geni.net+organization+BBN" pop="urn:publicid:IDN+gmoc.geni.net+pop+gpolab" type="foam" version="0.8.2"> <sliver approved="1" created="1342549645" creator="urn:publicid:IDN+gmoc.geni.net+contact+site-gpolab-grandfathered-slice" expires="1362114000" local_name="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82" slice_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+chaos-montreve-macaddr" slice_uuid="None" state="Up" uuid="b72b0a06-beb9-4be2-94ba-cfbd8654ad82"> <resource_mapping local_name="b72b0a06-beb9-4be2-94ba-cfbd8654ad82" resource="urn:publicid:IDN+openflow:foam:foam5.gpolab.bbn.com+datapath+04:4d:00:26:f1:3f:3b:00" type="flowspace"/> <resource_mapping local_name="b72b0a06-beb9-4be2-94ba-cfbd8654ad82" resource="urn:publicid:IDN+openflow:foam:foam5.gpolab.bbn.com+datapath+04:4d:00:12:e2:b8:a5:d0" type="flowspace"/> </sliver> <sliver approved="1" created="1342549645" creator="urn:publicid:IDN+gmoc.geni.net+contact+site-gpolab-grandfathered-slice" expires="1362114000" local_name="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+chaos-poblano1101-datapath:9c3476a5-dfe9-4d8c-9d2d-3b20d846f36a" slice_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+chaos-poblano1101-datapath" slice_uuid="None" state="Up" uuid="9c3476a5-dfe9-4d8c-9d2d-3b20d846f36a"> <resource_mapping local_name="9c3476a5-dfe9-4d8c-9d2d-3b20d846f36a" resource="urn:publicid:IDN+openflow:foam:foam5.gpolab.bbn.com+datapath+04:4d:00:12:e2:b8:a5:d0" type="flowspace"/> </sliver> </aggregate> <resource aggregate="foam5.gpolab.bbn.com:3626" description="" name="urn:publicid:IDN+openflow:foam:foam5.gpolab.bbn.com+datapath+04:4d:00:12:e2:b8:a5:d0" organization="urn:publicid:IDN+gmoc.geni.net+organization+BBN" pop="urn:publicid:IDN+gmoc.geni.net+pop+gpolab" state="Unknown" type="datapath"/> <resource aggregate="foam5.gpolab.bbn.com:3626" description="" name="urn:publicid:IDN+openflow:foam:foam5.gpolab.bbn.com+datapath+04:4d:00:26:f1:3f:3b:00" organization="urn:publicid:IDN+gmoc.geni.net+organization+BBN" pop="urn:publicid:IDN+gmoc.geni.net+pop+gpolab" state="Unknown" type="datapath"/> </gmoc_topology>
However, the last_update
time for the sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+chaos-montreve-macaddr:b72b0a06-beb9-4be2-94ba-cfbd8654ad82
is still 1342534801 (July).
The sliver table is not correctly updating based on submitted sliver data.
Change History (10)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
There are two problems here: 1) the contact being referenced as the creator of these slivers is not present in the database, and 2) the backend code does not complain when this happens. The method that handles slivers returns early instead of rejecting the submission with an appropriate error.
comment:3 Changed 12 years ago by
I updated the code to return an error when the creator for a sliver is either not found or is specified as NULL.
comment:4 Changed 12 years ago by
We agreed on channel to create a single user with urn: urn:publicid:IDN+gmoc.geni.net+contact+user-not-known
And have that manually submitted to the DB. If you don't have a contact, you should use this.
comment:5 Changed 12 years ago by
Also Chaos checked that the backend now complains if the contact isn't defined in the DB.
comment:6 Changed 12 years ago by
Owner: | changed from somebody to chaos@bbn.com |
---|
comment:7 Changed 12 years ago by
Priority: | critical → major |
---|
We found a second issue here, which is that the slices to which the slivers belonged were not defined in the database. I hacked in some manual pgeni.gpolab data to resolve this issue. Now i do see my slivers updated in the database, and the sliver/resource mappings look correct and up-to-date as well.
However, i disagree that the backend should complain when it discards a sliver submission due to an undefined contact address. Two things:
- The backend also silently discards slivers due to undefined slices. Those things are closely enough tied together (because contacts come from SAs) that it doesn't make sense for one to fail noisily and the other to fail silently. So we need a change one way or the other.
- The decision to silently ignore slivers that couldn't be recorded due to a missing slice was an intentional one we made before GEC14, basically on the theory that failing noisily on unknown slivers sheds a lot of heat and no light for aggregate operators, who might perfectly reasonably have slivers from non-GENI-affiliated SAs or from SAs which happened not to be monitoring at the moment. The aggregate operators can't fix those problems, so they shouldn't be pestered about them via e-mail, in my opinion.
We should come to an agreement about this and fix it.
Dropping the priority to major, since sliver submission works.
comment:8 Changed 12 years ago by
Owner: | changed from chaos@bbn.com to somebody |
---|
comment:10 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I need to test this using a contact which is not in the database. I think the right thing to do is to use my secondary cgolubit@pgeni.gpolab account:
- Get that account setup to use omni
- Create a slice on pgeni.gpolab using that account
- Create a sliver on foam5.gpolab using that slice and that account
- Submit data on tau-verde, and see whether or not i get an error
My data submission contained:
<sliver approved="1" created="1349291214" creator="urn:publicid:IDN+pgeni.gpolab.bbn.com+user+cgolubit" expires="1349381177" local_name="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+cgtest1:a40b7bfe-5504-4842-9807-96e000d19348" slice_urn="urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+cgtest1" slice_uuid="None" state="Down" uuid="a40b7bfe-5504-4842-9807-96e000d19348"/>
and was accepted by gmoc-db2. There is no cgolubit contact in gmoc-db2, so that means this is resolved.
Incidentally, i also notice in the web UI for foam5: https://gmoc-db2.grnoc.iu.edu/protected-openid/index.pl?method=aggregate_details;aggregate=foam5.gpolab.bbn.com, that there are no slivers shown. That's presumably related to this issue too.