Indeed, to realize a dragonflow implementation of BGPVPN API, the behavior needed is different than the one of the 'bagpipe' driver for BGPVPN. The BGPVPN driver framework already has everything in place to create a dragonflow driver without any dependency on the existing 'bagpipe' driver: subclassing the BGPVPNDriver [1] class is sufficient to have access to all the postcommit hooks, and interact with bagpipe-bgp from there.
Unless I missed something and the dragonflow driver would need to inherit some particular behavior from the existing bagpipe service plugin... ? If so, then we'd need to identify exactly which pieces would be reused.
Indeed, to realize a dragonflow implementation of BGPVPN API, the behavior needed is different than the one of the 'bagpipe' driver for BGPVPN. The BGPVPN driver framework already has everything in place to create a dragonflow driver without any dependency on the existing 'bagpipe' driver: subclassing the BGPVPNDriver [1] class is sufficient to have access to all the postcommit hooks, and interact with bagpipe-bgp from there.
Unless I missed something and the dragonflow driver would need to inherit some particular behavior from the existing bagpipe service plugin... ? If so, then we'd need to identify exactly which pieces would be reused.
[1] https:/ /github. com/openstack/ networking- bgpvpn/ blob/master/ networking_ bgpvpn/ neutron/ services/ service_ drivers/ driver_ api.py# L246