Open Stack

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

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

Also, I've created a WIP review of the initial database structure:
https://review.openstack.org/#/c/114671/

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!

-Brandon

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 [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).
> --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a DEFEERRED status! YAY!) --Also maybe a DELETED status.
> 
> -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.
> 
> Thanks,
> Brandon
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev