peeringdb: IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket
Problem
Originally reported in #875
The IX-F import currently maintains one ticket on the deskpro end for each ix-f conflict. Meaning that if a ticket gets resolved and the conflict occurs again later down the line, the message will go to the existing ticket, while the ticket status will remain resolved.
Proposals
A
On new IX-F conflict that already has a deskpro ticket use the deskpro api to check the existing ticket status and set it to awaiting_agent if it is currently resolved.
B
Instead create a new ticket for the conflict. This will need us to find a work around to the “Duplicate ticket” error the deskpro api currently returns if a ticket with the same subject already exists. A likely solution here would be to augment the ticket subject with a YYYY-MM-DD-<proc-id> suffix.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 22 (17 by maintainers)
Commits related to this issue
- IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket (#920) — committed to peeringdb/peeringdb by vegu 3 years ago
- Prep 2.29 (#1024) * django3, py39, lgtm, linting (#715) * IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket (#920) * fix recaptcha requirement fo... — committed to peeringdb/peeringdb by grizz 3 years ago
Hi @martinhannigan. Glad to have you participating.
The IX-F (Internet Exchange Federation) has not ever paid PeeringDB. That said, PeeringDB welcomes additional sponsorships: https://docs.peeringdb.com/misc/PeeringDB_Sponsorship_Levels.pdf
As I understand things (and folks should feel free to correct me where I am wrong), IX-F & Euro-IX developed a common schema for IXPs to use to export details. This schema is at: https://github.com/euro-ix/json-schemas
Many IXPs export this data. IXP Manager has this built in, while other IXPs write their own code to do an export. For example, the SeattleIX’s export - which I wrote - is at: https://www.seattleix.net/autogen/participants.json
Multiple entities use the exported data. Euro-IX uses it for: https://ixpdb.euro-ix.net/
PeeringDB supports the ability for IXPs to cause their IX-F JSON export to be processed by PeeringDB for the purposes of helping to make the data at PeeringDB be more accurate. We call it the “IX-F Importer” or “IX-F JSON Importer”, hence some GitHub issues with this name in the title. This process runs daily and is documented at: https://docs.peeringdb.com/ix-f-json-import-rules/
Some networks opt to allow the IX-F Importer to automatically populate their entries in cases where IXPs have indicated their presence or departure. Other networks choose to use the Importer’s “hints” to help auto-fill in missing data. Additionally, conflicted data (such as the wrong network having someone else’s IP assignment configured), can result in emails to the network or the IXP and sometimes results in a ticket for the Admin Committee to get involved. A presentation on these Importer features is up at https://docs.peeringdb.com/presentation/20200817-dtf-implementation.pdf and https://www.youtube.com/watch?v=mtT_HojbIPs .
To finally answer your question: When an IXP configures the URL to be used for their export to PeeringDB, they have a choice of whether to make the URL public or not, with a setting in the “IX-F Member Export URL Visibility” field. This is needed because some URLs include tokens/passwords to enable PeeringDB to query the data. Not all IXPs want this data freely accessible, or maybe they want to know who is querying.
This particular GitHub issue has to do with how to handle a duplicate conflict, with respect to whether re-open a previous ticket for the Admin Committee, or whether to create a new ticket. Generally, this kind of thing would be decided by the committee affected, since it affects their workload.
A - I’m leaning for A so that we don’t have to bounce between tickets to get the full story. I believe that’s similar to how Deskpro works now. We resolve something pending the user’s request and if they respond with additional data the same ticket shows up with the full thread of history. Easier than digging for the older ticket imo.