Closed nickpegg closed 6 years ago
@coxley - Pinging you to check this out since you were the one who opened the original issue (#206) :)
FYI, I've rebased this PR onto a new protocol-feature
branch since I want to get this PR and a future PR for the API updates together before they land into the develop
branch
A Protocol represents a routing protocol which is running over a circuit, such as BGP, OSPF, IS-IS, etc.
This commit includes only the model, I will implement the CRUD operations later once this model is solidified.
This is based on some experimentation and the conversation in #206. There are both
interface
andcircuit
fields available to store information relevant to different routing protocols.For example, OSPF is generally assigned on a per-interface level, but BGP typically needs information like a remote peer address (the address on the remote Interface of the Circuit) and optionally an update source (the local Interface on the Circuit).
The concrete fields on
Protocol
are meant to cover all cases, any other parameters, for example a BGP ASN, are meant to be attributes that are added to a Protocol object. To help with validation for needed attributes, a ProtocolType object is added. On aProtocolType
, you can define attributes onProtocol
which are required and if aProtocol
is missing any of those attributes is saved, aValidationError
will get raised.The tests show some example uses of ProtocolType, but when all the view code is added I'll be sure to update the documentation with some 'cookbooks' how how exactly to use these objects with the API.