[openstack-dev] [Octavia] Object Model and DB Structure

Eichberger, German german.eichberger at hp.com
Fri Aug 15 20:34:50 UTC 2014

--Basically no shareable entities.

That will make me insanely happy :-)

Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy instance - and a listener would be part of that haproxy. But I heard Stephen say that this so not so clear cut. So maybe listeners map to haproxy instances...


-----Original Message-----
From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] 
Sent: Thursday, August 14, 2014 10:17 PM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Octavia] Object Model and DB Structure

So I've been assuming that the Octavia object model would be an exact copy of the neutron lbaas one with additional information for Octavia.
However, after thinking about it I'm not sure this is the right way to go because the object model in neutron lbaas may change in the future, and Octavia can't just change it's object model when neutron lbaas/openstack lbaas changes it's object model.  So if there are any lessons learned we would like to apply to Octavia's object model now is the time.

Entity name changes are also on the table if people don't really like some of the names.  Even adding new entities or removing entities if there are good reasons isn't out of the question.

Anyway here are a few of my suggestions.  Please add on to this if you want.  Also, just flat out tell me I'm wrong on some of htese suggestions if you feel as such.

A few improvements I'd suggest (using the current entity names):
-A real root object that is the only top level object (loadbalancer).
--This would be 1:M relationship with Listeners, but Listeners would only be children of loadbalancers.
--Pools, Members, and Health Monitors would follow the same workflow.
--Basically no shareable entities.

-Provisioning status only on the root object (loadbalancer).

-Operating status on other entities
--ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members --Listeners have been mentioned but I'd like to hear more details on that.

-Adding status_description field in, or something similar.  Would only eixst on loadbalancer entity if loadbalancer is the only top level object.

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list