Hi Stephen, > Doug: What do you think of the idea of having both IPv4 and IPv6 attributes > on a 'load balancer' object? One doesn't need to have a single appliance > serving both types of addresses for the listener, but there's certainly a > chance (albeit small) to hit an async scenario if they're not.
I made the same suggestion in the bp review , so I have no issue with it. :-) I can think of at least one backend that pairs ip:port in their listener object, so the driver for that can implement the v4/v6 model natively with no issue (but not a true N:N). For the ones that don’t, at least the race condition outlined earlier is limited to two objects, which is ok if the use case is common enough to warrant it. I’d still prefer that issue be handled as far up the chain as possible, but I’d be ok. Doug From: Stephen Balukoff <sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, May 27, 2014 at 8:42 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint Hi y'all! On Tue, May 27, 2014 at 12:32 PM, Brandon Logan <brandon.lo...@rackspace.com<mailto:brandon.lo...@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. Is there such a thing as a 'possibly planned but not implemented design' to serve as a placeholder when considering other in-parallel blueprints and designs which could potentially conflict with the ability to implement an anticipated design like this? (I'm guessing "no." I really wish we had a better design tracking tool than blueprint.) Anyway, I don't have a problem with implementing 1:N right now. But, I do want to point out: The one and only common case I've seen where listener re-use actually makes a lot of sense (IPv4 and IPv6 for same listener) could be alleviated by adding separate ipv4 and ipv6 attributes to the loadbalancer object. I believe this was shot down when people were still calling it a VIP for philosophical reasons. Are people more open to this idea now that we're calling the object a 'load balancer'? ;) Does anyone have any other use cases where listener re-use makes sense? 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. Yep, totally on-board with 1:1 for pool and health monitor. 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. So, I think it does make sense when using L7 rules. And it's specifically like this: A pool is 'UP' if at least one non-backup member is 'UP' and 'DOWN' otherwise. This can be an important monitoring point if, for example, operations wants to be informed if the 'api pool' is down while the 'web frontend' pool is still up, in some meaningful way (ie. other than having to sort through a potential barrage of member down notifications to see wether any members of a given pool are still up.) Also, given that member status might be more than just 'UP' and 'DOWN' (eg. "PROVISIONING" or "DRAINING" might also be valid status types for certain kinds of back-ends.) It's harder for an operator to know whether a given pool is 'UP' or 'DOWN' without some kind of indication. Also note that the larger the pool, the less meaningful individual members' statuses are: If you've got 1000 servers in a pool, it's probably OK if 3-4 of them are 'down' at any given time. Having said this, if someone asks for the status of a pool, I'd be OK if the response was simply an array of statuses of each member in the pool, plus one 'summary' status (ie. as described above) and it's left to the user to do with that data whatever makes sense for their application. This would allow one to see, for example, that a pool with no members is by definition 'DOWN'. Are we going to allow a pool to be set administratively down? (ex. for maintenance on one pool of servers powering a listener, while other pools remain online and available.) In this case, having a response that says the pool is 'ADMIN_DOWN' probably also makes sense. Doug: What do you think of the idea of having both IPv4 and IPv6 attributes on a 'load balancer' object? One doesn't need to have a single appliance serving both types of addresses for the listener, but there's certainly a chance (albeit small) to hit an async scenario if they're not. Vijay: I think the plan here was to come up with an use an entirely different DB schema than the legacy Neutron LBaaS, and then retro-fit backward compatibility with the old user API once the new LBaaS service is functional. I don't think anyone here is suggesting we try to make the old schema work for the new API. Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807<tel:%28800%29613-4305%20x807>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
