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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
