Allow [test] records to be excluded from the IX-F export.
ichilton opened this issue · comments
Is your feature request related to a problem? Please describe.
We currently have some test members, for some testing we are in the middle of.
They are showing up in the IX-F import, which goes to PeeringDB etc.
Describe the solution you'd like
These records are easily identifiable as they have ASNs in the documentation range (64496 - 64511) and also have a 'Test Record' tag.
There are a few things here:
- The export should be skinnable, which would let us customise this behaviour for ourselves.
- There is an argument that documentation ASNs (64496 - 64511 / 65536 - 65551) should be excluded from the export by default.
- It would be good to have configuration options to be able to exclude records from the export, eg: by ASN, tag, etc.
Describe alternatives you've considered
We thought we could just use the skin to override the template for the export, but it appears not to be skinnable.
Hey @ichilton - good to hear from you.
The export should be skinnable, which would let us customise this behaviour for ourselves.
I'm inclined to disagree, sorry! This is an industry standard schema and while I appreciate why you're asking for it to be skinnable, my worries are:
- the schema has updated from v0.6 -> v.... -> v1.0 and will continue to evolve. Skinning causes issues here.
- an industry standard export format, to my mind, should be immutable
There is an argument that documentation ASNs (64496 - 64511 / 65536 - 65551) should be excluded from the export by default.
The flip side then is that IXPs that are testing on test / dev environments will take an opposite position.
It would be good to have configuration options to be able to exclude records from the export, eg: by ASN, tag, etc.
This would go completely against the purpose, advantage and sales pitch of IX-F Export: complete, accurate and up to date information about an IXP at a point in time.
While being able to disable certain members for testing might be desirable, it will create an avenue for not having complete, accurate and up to date information about an IXP and devalue the prospect of the IX-F Export overall.
Ultimately, your use case seems to be based on using a production IXP Manager system for some form of testing and the feature request emerges from that. What I'd suggest is to try and handle this by replicating the database into a development box and do your testing / lab work there?
If you must, IXP Manager is open source, you can just exclude those ASNs yourself without us developing a feature in the code base that will create, to my mind, the issues I have alluded to above?
Submitted a PR: #839 to make this a configurable option.
There are a few situations where, within the production network, we don't want to stuff to end up in peeringdb.
- Temporary or transitional setups
- Where we want the automation to provision the ports correctly but not (yet) put it in peeringdb, as the network concerned is not ready, or they don't want people to try setting up peering sessions yet.
- Pre-production testing with resellers etc where we have to use their real ports, on the real network and carry out 'PoC' testing to demonstrate that it will work, but with 'test' resold networks.
We've had a few situations recently where it's all worked fine in the test environment as far as we can test things, but in some cases it may not be realistic to expect us to have endless hardware of the correct model switches available to replicate the live network, replicate all of IXP Manager, the database, all of the automation, then move the reseller (assuming they have a spare port/crossconnect) to their own little switch, move that switch to a test environment which identically replicates the live network.
It's perhaps not ideal, but we don't always have the resource to test / debug every given scenario off-line. (There's usually only one spare switch of each model available, plus some older models we've taken out) and switches can't be provisioned by both the test and production automation simultaneously. (Or specify that "these resold VLANS, on this port, on this switch, are testing, these are live" etc.)
Hi @barryo!
Just getting chance to follow up on this.
You make good arguments against skinning and excluding documentation/test ASNs by default - that makes total sense.
I do disagree with this though:
This would go completely against the purpose, advantage and sales pitch of IX-F Export:
complete, accurate and up to date information about an IXP at a point in time.
I see your point here, but it's not complete/accurate if it includes data that we specifically do not want to share, for example, test data.
I don't see the harm in allowing a configuration option to exclude certain things, as that is the users choice to explicitly configure that and I think it can be assumed that if they dig out that option and implement it, that they should know what they are doing and why.
Thanks,
Ian
I'm inclined to disagree, sorry! This is an industry standard schema and while I appreciate why you're asking for it to be skinnable, my worries are:
- the schema has updated from v0.6 -> v.... -> v1.0 and will continue to evolve. Skinning causes issues here.
I disagree here. You can have a template per version. So if version 1.1 comes out, you would just add that. The end-user would then re-skin 1.1 if they wanted to.
- an industry standard export format, to my mind, should be immutable
There is a use case here, and I've just submitted another one where skinning the IX-F could be an easy answer. Neither of these use cases violates the IX-F format.
The PR from @listerr looks good and we will merge once he assesses some tweaks we pushed.