uld accommodate 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 Mo
.@rackspace.com>]
> Sent: Sunday, August 17, 2014 8:57 PM
> To:
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure
>
> Oh hello again!
>
> You know the drill!
>
> On
> single haproxy) - 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
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 request
xy) - 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: opensta
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 -0700, Stephen Balukoff wrote:
> > Hi Brandon,
> >
> >
> > Response
e 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 Model and DB Structure
Oh hello again!
You know the dril
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
> wrote:
> Comments in-line
>
> On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff
Hi Brandon,
Responses in-line:
On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
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, TLS-related objects
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
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 shar
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 th
--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 ha
13 matches
Mail list logo
