PeerGroupAddressFamily and PeerEndpointAddressFamily #132
Conversation
There was a problem hiding this comment.
I like the direction of the changes!
Adding more specific models requires more UI/API interactions from the user to create a new peering.
I think I could add following features:
- in the Routing Instance create form , allow to create Routing-Instance specific AFs based on AddressFamilyTemplate
- in the Peering form , auto-create PeerEndpointAddressFamily based on selected available AFs
- in the PeerGroup create form , allow to auto-create PeerGroupAddressFamily
Those should be out of scope for this PR , but let's see if we could add them next ?
| super().__init__(*args, **kwargs) | ||
|
|
||
| if self.initial.get("routing_instance"): | ||
| self.fields["routing_instance"].disabled = True |
There was a problem hiding this comment.
Why we should be dropping this? My idea was to prevent moving PeerGroups between Routing Instances
There was a problem hiding this comment.
This prevents us from prepopulating the routing_instance via query parameters, e.g. on the RoutingInstance detail page the "Add a Peer Group" button that I added links to /plugins/bgp-models/peer-groups/add/?routing_instance=<uuid>. Might just need to rework how this logic is written in order to still enforce no changes to an existing peer-group routing_instance?
| @@ -124,6 +139,17 @@ | |||
| ), | |||
| ), | |||
| ), | |||
| NavMenuItem( | |||
| link="plugins:nautobot_bgp_models:peerendpointaddressfamily_list", | |||
| name="Peer Endpoint Address-families (AFI-SAFI)", | |||
There was a problem hiding this comment.
Long term, I think we should "activate" address families during peering creation
So that in the "create" peering form we just enable specific address families and this results in PeerEndpointAddressFamili objects created.
There was a problem hiding this comment.
agreed, this would be nice from a UX standpoint.
There was a problem hiding this comment.
Will be partly addressed by #135.
| "import_policy": ["peer_group", "peer_group.peergroup_template"], | ||
| "source_ip": ["peer_group"], |
There was a problem hiding this comment.
TODO: Without a data migration, this will result in the data loss for existing users.
There was a problem hiding this comment.
Agreed, but we're still pre-1.0 here, and I'd argue the existing data is "wrong". Let's document it in the change log for sure, but I can't see a way to do a data migration since there's no indication which afi_safi the policies should be migrated to.
nautobot_bgp_models/templates/nautobot_bgp_models/peerendpointaddressfamily_retrieve.html
Show resolved
Hide resolved
|
LGTM, ship it! |
Closes #26.
PeerGroupAddressFamilyandPeerEndpointAddressFamilydata models.extra_attributestoAddressFamilymodel.import_policy,export_policy, andmultipathfromPeerGroupTemplate,PeerGroup, andPeerEndpointmodels, as per IOS XR CLI and the openconfig-bgp YANG model, these are address-family-specific attributes. (I'm open to revisiting this, as I do see that the Juniper config CLI configures policies at the peer-group level rather than at the peer-group-address-family level...)