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

2014-08-18 Thread Eichberger, German
:-) Thanks, German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Sunday, August 17, 2014 8:57 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure Oh hello again! You know the drill! On Sat

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

2014-08-18 Thread Brandon Logan
) - so having that would be great. I like the proposed status :-) Thanks, German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Sunday, August 17, 2014 8:57 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Octavia] Object

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

2014-08-18 Thread Stephen Balukoff
Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Sunday, August 17, 2014 8:57 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure Oh hello again! You know the drill! On Sat, 2014-08-16 at 11:42

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

2014-08-18 Thread Eichberger, German
List (not for usage questions) Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure Yes, I'm advocating keeping each listener in a separate haproxy configuration (and separate running instance). This includes the example I mentioned: One that listens on port 80 for HTTP requests

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

2014-08-18 Thread Stephen Balukoff
status :-) Thanks, German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Sunday, August 17, 2014 8:57 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure Oh hello again! You

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

2014-08-18 Thread Eichberger, German
) Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure Yes, I'm advocating keeping each listener in a separate haproxy configuration (and separate running instance). This includes the example I mentioned: One that listens on port 80 for HTTP requests and redirects everything

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

2014-08-18 Thread Stephen Balukoff
that. German *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Monday, August 18, 2014 2:43 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Octavia] Object Model and DB Structure German-- By 'VIP' do you mean something

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

2014-08-17 Thread Brandon Logan
Oh hello again! You know the drill! On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote: Hi Brandon, Responses in-line: On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Comments in-line On Fri, 2014-08-15 at 17:18

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

2014-08-16 Thread Stephen Balukoff
Hi Brandon, Responses in-line: On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Comments in-line On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote: Hi folks, I'm OK with going with no shareable child entities (Listeners, Pools, Members,

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

2014-08-15 Thread Eichberger, German
--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

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

2014-08-15 Thread Brandon Logan
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

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

2014-08-15 Thread Stephen Balukoff
Hi folks, I'm OK with going with no shareable child entities (Listeners, Pools, Members, TLS-related objects, L7-related objects, etc.). This will simplify a lot of things (like status reporting), and we can probably safely work under the assumption that any user who has a use case in which a

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

2014-08-15 Thread Brandon Logan
Comments in-line On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote: Hi folks, I'm OK with going with no shareable child entities (Listeners, Pools, Members, TLS-related objects, L7-related objects, etc.). This will simplify a lot of things (like status reporting), and we can