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 deployments will
never need to share objects, except for a few cases-- those cases (of 1:N)
relationships are:
* Loadbalancers must be able to have many Listeners
*
Hi,
I agree that the most important thing is to conclude how status properties are
being managed and handled so it will remain consistent as we move along.
I am fine with starting with a simple model and expending as need to be.
The L7 implementation is ready waiting for the rest of the model to
+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
German-- but the point is that sharing apparently has no effect on the
number of permutations for status information. The only difference here is
that without sharing it's more work for the user to maintain and modify
trees of objects.
On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German
Hi Brandon,
Yeah, in your example, member1 could potentially have 8 different statuses
(and this is a small example!)... If that member starts flapping, it means
that every time it flaps there are 8 notifications being passed upstream.
Note that this problem actually doesn't get any better if
Hi,
I apologize for the long delays, it is hectic time for me at work.
Stephen, I agree that concluding the status discussion will lead to an easier
discussion around relationships and sharing. So do this first if acceptable by
everyone.
Brandon, you got this right. This is the concept that I
Brandon, can you please explain further (1) bellow?
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Tuesday, November 25, 2014 12:23 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Hi Samuel,
We've actually been avoiding having a deeper discussion about status in
Neutron LBaaS since this can get pretty hairy as the back-end
implementations get more complicated. I suspect managing that is probably
one of the bigger reasons we have disagreements around object sharing.
Perhaps
My impression is that the statuses of each entity will be shown on a
detailed info request of a loadbalancer. The root level objects would
not have any statuses. For example a user makes a GET request
to /loadbalancers/{lb_id} and the status of every child of that load
balancer is show in a
Hi Stephen,
1. The issue is that if we do 1:1 and allow status/state to proliferate
throughout all objects we will then get an issue to fix it later, hence even if
we do not do sharing, I would still like to have all objects besides LB be
treated as logical.
2. The 3rd use case
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
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
12 matches
Mail list logo
