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.lo...@rackspace.com] > Sent: Thursday, August 14, 2014 10:17 PM > To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
