Oh hello again! You know the drill!
On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote: > Hi Brandon, > > > Responses in-line: > > On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan > <brandon.lo...@rackspace.com> wrote: > Comments in-line > > On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote: > > Hi folks, > > > > > > I'm OK with going with no shareable child entities > (Listeners, Pools, > > Members, TLS-related objects, L7-related objects, etc.). > This will > > simplify a lot of things (like status reporting), and we can > probably > > safely work under the assumption that any user who has a use > case in > > which a shared entity is useful is probably also technically > savvy > > enough to not only be able to manage consistency problems > themselves, > > but is also likely to want to have that level of control. > > > > > > Also, an haproxy instance should map to a single listener. > This makes > > management of the configuration template simpler and the > behavior of a > > single haproxy instance more predictable. Also, when it > comes to > > configuration updates (as will happen, say, when a new > member gets > > added to a pool), it's less risky and error prone to restart > the > > haproxy instance for just the affected listener, and not for > all > > listeners on the Octavia VM. The only down-sides I see are > that we > > consume slightly more memory, we don't have the advantage of > a shared > > SSL session cache (probably doesn't matter for 99.99% of > sites using > > TLS anyway), and certain types of persistence wouldn't carry > over > > between different listeners if they're implemented poorly by > the > > user. :/ (In other words, negligible down-sides to this.) > > > This is fine by me for now, but I think this might be > something we can > revisit later after we have the advantage of hindsight. Maybe > a > configurable option. > > > Sounds good, as long as we agree on a path forward. In the mean time, > is there anything I'm missing which would be a significant advantage > of having multiple Listeners configured in a single haproxy instance? > (Or rather, where a single haproxy instance maps to a loadbalancer > object?) No particular reason as of now. Just feel like that could be something that could hinder a particular feature or even performance in the future. It's not rooted in any fact or past experience. > > I have no problem with this. However, one thing I often do > think about > is that it's not really ever going to be load balancing > anything with > just a load balancer and listener. It has to have a pool and > members as > well. So having ACTIVE on the load balancer and listener, and > still not > really load balancing anything is a bit odd. Which is why I'm > in favor > of only doing creates by specifying the entire tree in one > call > (loadbalancer->listeners->pool->members). Feel free to > disagree with me > on this because I know this not something everyone likes. I'm > sure I am > forgetting something that makes this a hard thing to do. But > if this > were the case, then I think only having the provisioning > status on the > load balancer makes sense again. The reason I am advocating > for the > provisioning status on the load balancer is because it still > simpler, > and only one place to look to see if everything were > successful or if > there was an issue. > > > Actually, there is one case where it makes sense to have an ACTIVE > Listener when that listener has no pools or members: Probably the 2nd > or 3rd most common type of "load balancing" service we deploy is just > an HTTP listener on port 80 that redirects all requests to the HTTPS > listener on port 443. While this can be done using a (small) pool of > back-end servers responding to the port 80 requests, there's really no > point in not having the haproxy instance do this redirect directly for > sites that want all access to happen over SSL. (For users that want > them we also insert HSTS headers when we do this... but I digress. ;) > ) > > > Anyway, my point is that there is a common production use case that > calls for a listener with no pools or members. Yeah we do HTTPS redirect too (or HTTP redirect as I would call it...I could digress myself). I don't think its common for our customers, but it obviously should still be supported. Also, wouldn't that break the only one listener per instance rule? Also also, I think haproxy 1.5 has "redirect scheme" option that might do away with the extra frontend section. I could be wrong though. > > > Again though, what you've proposed I am entirely fine with > because it > works great with having to create a load balancer first, then > listener, > and so forth. It would also work fine with a single create > call as > well. > > > We should probably create more formal API documentation, eh. :) (Let > me pull up my drafts from 5 months ago...) What I'm hoping the API will look like will be different than those drafts, similar though. So they're probably a good starting point. Then again the neutron lbaas api google doc is probably a good one too. > > > > > I don't think that these kinds of status are useful / > appropriate for > > Pool, Member, Healthmonitor, TLS certificate id, or L7 > Policy / Rule > > objects, as ultimately this boils down to configuration > lines in an > > haproxy config somewhere, and really the Listener status is > what will > > be affected when things are changed. > > > Total agreement on this. > > > > I'm basically in agreement with Brandon on his points with > operational > > status, though I would like to see these broken out into > their various > > meanings for the different object types. I also think some > object > > types won't need an operational status (eg. L7 Policies, > > healthmonitors, etc.) since these essentially boil down to > lines in an > > haproxy configuration file. > > > Yeah I was thinking could be more descriptive status names for > the load > balancer and listener statuses. I was thinking load balancer > could have > PENDING_VIP_CREATE/UPDATE/DELETE, but then that'd be painting > us into a > corner. More general is needed. With that in mind, the > generic > PENDING_CREATE/UPDATE/DELETE is adequate enough as long as the > docs > explain what they mean for each object clearly. > > > Right. Let's get this documented. :) Or rather-- let's get drafts of > this documentation going in gerrit so people can give specific > feedback. (I'm happy to work on this, so long as I'm not a blocker on > anything else-- I want to make sure anyone who wants to put time into > the Octavia project knows how they can be useful, eh. It's a major pet > peeve of mine to find out after the fact that somebody was waiting on > something for me, and that this was a blocker for them being > productive.) I like your documentation skills and attention to detail. If you don't mind doing it, unless someone else wants something to do. > > Stephen > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev