RFE: project_id database field is redundant on many Octavia objects
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
octavia |
Invalid
|
Wishlist
|
Unassigned |
Bug Description
Right now, the following tables in the Octavia database all contain a project_id field:
member
health_monitor
pool
load_balancer
listener
Of the above, everything except load_balancer is ultimately a descendant of the load_balancer, and none of these descendant objects can exist independently of a load_balancer. Moreover, it is not valid for a descendant object's project_id to differ from its ancestor load_balancer's project_id.
Therefore, whatever we're storing in those tables' project_id field is just redundantly copying its ancestor load_balancer's project_id. This makes our database and code less DRY, which could lead to problems where a load_balancer and one of its descendants have a different project_id (either due to a bug in the code, or a database administrator doing the wrong thing with one of these fields in the database directly).
We should collapse this down and only store the project_id where it's important: On the load_balancer. Any references to a descendant object's project_id should instead look to its ancestor load_balancer object instead.
For example, in octavia/
@property
def project_id(self):
return self.pool.
By following this pattern instead, we could allow nearly every object in our database model to easily make its ancestor project_id usable/visible in the code without bloating our object models in the database, if we want to.
(And we should drop the project_id field from all database tables except the load_balancer table.)
Changed in octavia: | |
importance: | Undecided → Wishlist |
I thought this too, but when I made a patch to prepare for it, I was told we AREN'T going to do this? I don't know that the extra DB access to trace the project_id from the higher level objects is really that bad, as the MAXIMUM depth is about 4, for most objects it's just to the parent...