Open Stack

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.