Opened 9 years ago

Last modified 9 years ago

#1207 new

Repeated AddPersonToSite errors

Reported by: Aaron Helsinger Owned by:
Priority: major Milestone:
Component: I2AM Version: SPIRAL6
Keywords: Cc:,


Some people run into repeated instances of the error message "AddPersonToSite: Invalid argument: No such site" in the same project and slice. And then it stops. And some people do not see this at all, in the same project.

For example, in the GEC19 project (after it had been used repeatedly), people saw this - usually with slice names like 'iastitch2' or 'stitch-9'.

Change History (8)

comment:1 Changed 9 years ago by Aaron Helsinger

Cc: added

comment:2 Changed 9 years ago by Aaron Helsinger

Tony says this appears due to old deprecated code in the MAX aggregate manager. He sent a patched version to Xi.

comment:3 Changed 9 years ago by Aaron Helsinger

After applying code from Tony at both MAX and ION we still see this error. Planning a joint debugging session.

comment:4 Changed 9 years ago by Hussamuddin Nasir

just across the same error when trying to stiching between Ig-GPO and IG-Utah using omni 2.5 and the omni config generated from the portal.

Here my solution (or maybe i was just lucky)

In my omni config , i set

useslicemembers = False and users = <my user id >

This by default has my user id and the Project Lead's id since he/she is added automatically as an admin. I remove the project lead's user id so that it lists only one user.

Something in the error message from ION suggested it was unable to add a second user so i tried this.

{'output': "Internal API error: <Fault 102: 'person_id 2: AddPersonToSite: Invalid argument: No such site'>", 'geni_api': 2, 'code': {'am_type': 'sfa', 'geni_code': 5, 'am_code': 5}, 'value': }

13:14:40 WARNING stitcher: Stitching failed but will retry: Reservation request impossible at <Aggregate ion>. Aggregate had an internal error: AMAPIError: Error from Aggregate: code 5. sfa AM code: 5: Internal API error: <Fault 102: 'person_id 2: AddPersonToSite:...

comment:5 Changed 9 years ago by Aaron Helsinger

The error has to do with SFA talking to the myplc backend, but Tony&Xi now think ION doesn't need a myplc at all. So Xi & Tony will work to get rid of it (simplifying things in the process).

Additionally, Xi has tested commenting out the 3 calls that cause the error (we think) and saw no ill effects.

        #site = slices.verify_site(hrn, slice_record, peer, sfa_peer)
        #slice = slices.verify_slice(hrn, slice_record, peer, sfa_peer)
        #persons = slices.verify_persons(hrn, slice, users, peer, sfa_peer)

The error says that the URN was transformed in some inconsistent way apparently.

Luisa managed to reproduce the error while Tony was watching the logs, using the 'tutorial' project.

comment:6 Changed 9 years ago by Aaron Helsinger

Xi commented out those 3 lines at both MAX and ION. So far, testing shows no problems.

Meanwhile Xi will work on removing MyPLC altogether.

comment:7 Changed 9 years ago by Aaron Helsinger

Xi reports the MAX AM runs fine with no MyPLC and no postgres.

comment:8 Changed 9 years ago by

I have run ~150 stitched slivers since the removal of MyPLC using both MAX and ION aggregates. I have not seen any occurrences of the problem.

Note: See TracTickets for help on using tickets.