Open Stack

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.logan at RACKSPACE.COM] 
> Sent: Sunday, August 17, 2014 8:57 PM
> To: openstack-dev at 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.logan at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev