[openstack-dev] [Octavia] Object Model and DB Structure
brandon.logan at RACKSPACE.COM
Mon Aug 18 03:56:48 UTC 2014
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
> > safely work under the assumption that any user who has a use
> case in
> > which a shared entity is useful is probably also technically
> > enough to not only be able to manage consistency problems
> > 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
> > haproxy instance for just the affected listener, and not for
> > 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
> > between different listeners if they're implemented poorly by
> > 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
> 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
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
> (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
> 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
> and so forth. It would also work fine with a single create
> call as
> 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
> > status, though I would like to see these broken out into
> their various
> > meanings for the different object types. I also think some
> > 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
> PENDING_CREATE/UPDATE/DELETE is adequate enough as long as the
> 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
I like your documentation skills and attention to detail. If you don't
mind doing it, unless someone else wants something to do.
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev