foam5.gpolab.bbn.com sliver data is not being submitted to the database

[chaos@bbn.com]

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.

[chaos@bbn.com]

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.

[Kevin Bohan]

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.

[Kevin Bohan]

I updated the code to return an error when the creator for a sliver is either not found or is specified as NULL.

[sedwards@bbn.com]

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.

[sedwards@bbn.com]

Also Chaos checked that the backend now complains if the contact isn't defined in the DB.

[chaos@bbn.com]

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.

[sedwards@bbn.com]

Chaos is testing.

[chaos@bbn.com]

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.