Hi German,
On Mon, Aug 18, 2014 at 3:10 PM, Eichberger, German < german.eichber...@hp.com> wrote: > No, I mean with VIP the original meaning more akin to a Floating IP… > > I think that's what I was describing below. But in any case, yes-- the model we are describing should accommodate that. > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Monday, August 18, 2014 2:43 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Octavia] Object Model and DB Structure > > > > German-- > > > > By 'VIP' do you mean something roughly equivalent to 'loadbalancer' in the > Neutron LBaaS object model (as we've discussed in the past)? That is to > say, is this thingy a parent object to the Listener in the hierarchy? If > so, then what we're describing definitely accommodates that. > > > > (And yes, we commonly see deployments with listeners on port 80 and port > 443 on the same virtual IP address.) > > > > Stephen > > > > On Mon, Aug 18, 2014 at 2:16 PM, Eichberger, German < > german.eichber...@hp.com> wrote: > > Hi Steven, > > > > In my example we don’t share anything except the VIP J So my motivation > is if we can have two listeners share the same VIP. Hope that makes sense. > > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Monday, August 18, 2014 1:39 PM > *To:* OpenStack Development Mailing List (not for usage questions) > > > *Subject:* Re: [openstack-dev] [Octavia] Object Model and DB Structure > > > > Yes, I'm advocating keeping each listener in a separate haproxy > configuration (and separate running instance). This includes the example I > mentioned: One that listens on port 80 for HTTP requests and redirects > everything to the HTTPS listener on port 443. (The port 80 listener is a > simple configuration with no pool or members, and it doesn't take much to > have it run on the same host as the port 443 listener.) > > > > I've not explored haproxy's new redirect scheme capabilities in 1.5 yet. > Though I doubt it would have a significant impact on the operational model > where each listener is a separate haproxy configuration and instance. > > > > German: Are you saying that the port 80 listener and port 443 listener > would have the exact same back-end configuration? If so, then what we're > discussing here with no sharing of child entities, would mean that the > customer has to set up and manage these duplicate pools and members. If > that's not acceptable, now is the time to register that opinion, eh! > > > > Stephen > > > > On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > > 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 > > > > > > -- > 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 > > > > > > -- > 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 > > -- 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