: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Cases that led us to adopt this.
So... I should probably note that I see the case where a user actually shares
object as being the exception. I expect that 90% of
tatuses. Showing these in the body of load
> balancer details can get quite large.
>
> I hope this makes sense because my brain is ready to explode.
>
> Thanks,
> Brandon
>
>
> On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
> > Brandon, can you please expl
+1
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, December 05, 2014 7:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Cases that led us to adopt this.
German-- but the point
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Thursday, December 04, 2014 9:17 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
> Use Cases that led us to adopt
, December 04, 2014 9:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Cases that led us to adopt this.
Hi Brandon,
Yeah, in your example, member1 could potentially have 8 different statuses (and
this is
>
> I hope this makes sense because my brain is ready to explode.
>
> Thanks,
> Brandon
>
> On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
> > Brandon, can you please explain further (1) bellow?
> >
> > -Original Message-----
> > From: Brandon Logan
logical.
> >
> > 2. The 3rd use case bellow will not be reasonable without
> > pool sharing between different policies. Specifying different
> > pools which are the same for each policy make it non-started
> > to me.
> >
es. Specifying different
> pools which are the same for each policy make it non-started
> to me.
>
>
>
> -Sam.
>
>
>
>
>
>
>
>
all objects besides LB be treated as
> logical.
>
> 2. The 3rd use case bellow will not be reasonable without
> pool sharing between different policies. Specifying different
> pools which are the same for each policy make it non-started
>
h are the same for each policy make it non-started
> to me.
>
>
>
> -Sam.
>
>
>
>
>
>
>
> From: Stephen Balukoff [mailto:sbaluk...@bluebox.
>
>
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Friday, November 21, 2014 10:26 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
>
Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Cases that led us to adopt this.
I think the idea was to implement 1:1 initially to reduce the amount of code
and operational complexity we'd have to deal with in initial revi
I think the idea was to implement 1:1 initially to reduce the amount of
code and operational complexity we'd have to deal with in initial revisions
of LBaaS v2. Many to many can be simulated in this scenario, though it does
shift the burden of maintenance to the end user. It does greatly simplify
t
Hi,
Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would
like to remind everyone why we choose to follow a model where pools and
listeners are shared (many to many relationships).
Use Cases:
1. The same application is being exposed via different LB objects.
For example
14 matches
Mail list logo
