de-duplicate route_targets and {import,export}_rts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
networking-bgpvpn |
Fix Released
|
Medium
|
Mathieu Rohon | ||
Juno |
Won't Fix
|
Medium
|
Unassigned | ||
Kilo |
Won't Fix
|
Medium
|
Unassigned | ||
Liberty |
Won't Fix
|
Medium
|
Mathieu Rohon |
Bug Description
API Spec text says:
------------------
The implementation will rely on three tables:
* one for BGPVPN objects
* one to define the 1-n relation ship between a BGPVPN and a set of Networks
* one to define the 1-n relation ship between a BGPVPN and a set of Routers
These two last tables will not rely on foreign keys with the Neutron-owned
tables for Networks and Routers.
The information stored in these tables will reflect what is exposed on the
API, with an exception for route_targets:
* this list will not be present in the database
* on an API request to create or modify a BGPVPN: the route_targets
parameter will be merged without duplicates with import_rts before storing
import_rts, ditto for export_rts
* on an API request to show a BGPVPN:
* route_targets will be synthesized to include RTs present in both
export_rts and import_rts
* import_targets will contain only RTs not in common with export_rts
* export_targets will contain only RTs not in common with import_rts
-------
The current code does not yet do the above.
What is missing :
- remove the route_targets field from the db
- on API create and update, populate import_rts and export_rts taking into account route_targets
- on API get, recreate route_targets
Changed in bgpvpn: | |
milestone: | none → liberty |
Changed in bgpvpn: | |
importance: | Medium → Critical |
importance: | Critical → Medium |
If we do not do it now, then doing it later will be a real pain because the db content would have to be deduplicated for a proper migration.
However, giving more thinking to that, I'm not even sure we should do this de-duplication.
The reason is that with the deduplication, when an API user reads an object that had been created earlier, what he will get for the route_target fields will be different from what he will have specified initially.
I am not sure that the possible confusion coming from this is worth the very minor optimisation in the DB fields.