Hi German, I don't think it is a requirement that those two frontend sections (or listen sections) have to live in the same config. I thought if they were listening on the same IP but different ports it could be in two different haproxy instances. I could be wrong though.
Thanks, Brandon On Mon, 2014-08-18 at 17:21 +0000, Eichberger, German wrote: > Hi, > > My 2 cents for the multiple listeners per load balancer discussion: We have > customers who like to have a listener on port 80 and one on port 443 on the > same VIP (we had to patch libra to allow two "listeners" in one single > haproxy) - so having that would be great. > > I like the proposed status :-) > > Thanks, > German > > -----Original Message----- > From: Brandon Logan [mailto:brandon.lo...@rackspace.com] > Sent: Sunday, August 17, 2014 8:57 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure > > 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 > > _______________________________________________ > 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
