Open Stack

Thanks, Brandon.  My opinion, reproduced from an IRC conversation that we
had earlier today:

I don't have a strong objection, just an implementation shudder.  Of the
two backends that I'm familiar with, they support 1:N, not N:N  So, we
fake it by duping listeners on the fly. But, consider the extreme, say
1000 LB's and 1 shared listener.  How long does it take to create 1000
listeners?  What happens when it fails on 998?  Ok, we rollback.  What
happens when the rollback fails?  Inconsistent state.  Driver's can't
async.  Driver's can't run cleanup routines later.

What about when half the LB's have lit listeners and the other half don't;
does the db say that N:N link is there yet or not?

Shrink the allowed number of listeners and the window of pain gets
smaller, but at operator scale, even a small window will get hit.

Thanks,

doug

On 5/27/14, 1:32 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM> wrote:

>Referencing this blueprint:
>https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel
>-improvement.rst
>
>Anyone who has suggestions to possible issues or can answer some of
>these questions please respond.
>
>
>1. LoadBalancer to Listener relationship M:N vs 1:N
>The main reason we went with the M:N was so IPv6 could use the same
>listener as IPv4.  However this can be accomplished by the user just
>creating a second listener and pool with the same configuration.  This
>will end up being a bad user experience when the listener and pool
>configuration starts getting complex (adding in TLS, health monitors,
>SNI, etc). A good reason to not do the M:N is because the logic on might
>get complex when dealing with status.  I'd like to get people's opinions
>on this on whether we should do M:N or just 1:N.  Another option, is to
>just implement 1:N right now and later implement the M:N in another
>blueprint if it is decided that the user experience suffers greatly.
>
>My opinion: I like the idea of leaving it to another blueprint to
>implement.  However, we would need to watch out for any major
>architecture changes in the time itis not implemented that could make
>this more difficult than what it needs to be.
>
>2. Pool to Health Monitor relationship 1:N vs 1:1
>Currently, I believe this is 1:N however it was suggested to deprecate
>this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
>objections to channging to 1:1?
>
>My opinion: I'm for 1:1 as long as there aren't any major reasons why
>there needs to be 1:N.
>
>3. Does the Pool object need a status field now that it is a pure
>logical object?
>
>My opinion: I don't think it needs the status field.  I think the
>LoadBalancer object may be the only thing that needs a status, other
>than the pool members for health monitoring.  I might be corrected on
>this though.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev