RFE: project_id database field is redundant on many Octavia objects

Bug #1624113 reported by Stephen Balukoff
6
This bug affects 1 person
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/db/models.py, instead of making the Member class include the base_models.ProjectMixin class type, we could instead create a @property method in the Member class that works like the following:

    @property
    def project_id(self):
        return self.pool.load_balancer.project_id

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
Revision history for this message
Adam Harwell (adam-harwell) wrote :

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...

Revision history for this message
Gregory Thiemonge (gthiemonge) wrote : auto-abandon-script

Abandoned after re-enabling the Octavia launchpad.

Changed in octavia:
status: New → Invalid
tags: added: auto-abandon
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.