Yeah, need details on that.  Maybe he's talking about having haproxy
listen on many ips and ports, each one being a separate front end
section and in the haproxy config with each mapped to its own

Even if that is the case, the load balancer + listener woudl still make
up one of those frontends so the mapping would still be correct.
Though, maybe a different structure would make more sense if that is the

Also, I've created a WIP review of the initial database structure:

Added my own comments so everyone please look at that.  Stephen, if you
could comment on what German mentioned that'd be great.

Have a good weekend!


On Fri, 2014-08-15 at 20:34 +0000, Eichberger, German wrote:
> --Basically no shareable entities.
> +1
> 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...
> German
> -----Original Message-----
> From: Brandon Logan [] 
> Sent: Thursday, August 14, 2014 10:17 PM
> To:
> 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).
> DEFEERRED status! YAY!) --Also maybe a DELETED status.
> -Operating status on other entities
> --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.
> Thanks,
> Brandon
> _______________________________________________
> OpenStack-dev mailing list
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to