Hi Craig, I was attempting to avoid haproxy-specific terminology here, but some of those attributes are on the listener (ie. keepalive = 0 would be equivalent to httpclose). Other options (like adding headers) are expressed through the layer-7 functionality.
So, we have yet to update the API to correspond with this object diagram, but if you recall the API I linked on the list a couple weeks ago ( https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing) look in the section on L7 policies and L7 rules. (Note also that we don't yet have group consensus on the specifics of implementing the L7 stuff-- but adding headers would definitely fall in that category, eh.) Stephen On Wed, May 14, 2014 at 3:04 PM, Craig Tracey <[email protected]> wrote: > Thanks Stephen, > > One nit and one question.... > - For each of the tables with status fields we will want to have > status_description fields as well. This is already a part of the V2 models. > - How does this model handle things like implementation-specific options > and/or things like additional headers? I'm thinking of some of those very > common cases with http/https...X-Forwarded-For, httpclose, etc. > > Best, > Craig > > > On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff > <[email protected]>wrote: > >> Aah-- and here's a small error correction. :) >> >> Please also note: >> * We're not yet in consensus on the L7 or SSL related objects, but the >> Loadbalancer, Listener, Pool, and Member should probably not change at this >> point (unless there are major objections voiced in the very near term). >> * I've tried to use color coordination to indicate different logical >> parts that can probably be implemented in different blueprints / by >> different engineering teams. >> * The LBtoListener object is grayed out because it will need to exist in >> the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 >> common use case), but should not be directly addressable via the user API. >> (This is also the reason it's got no tenant_id.) >> * The vip group and vip anti group stuff is meant to solve the vip >> colocation / apolocation problem. These are optional objects that don't >> need to be created unless a user has colocation / apolocation needs. (I'd >> be happy to run anyone through the logic on how these work, as it's >> probably not immediately intuitive.) >> >> Stephen >> >> >> >> On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff <[email protected] >> > wrote: >> >>> Also, apologies for the crappy formatting. I like gv files as they're >>> easily tracked in a text-based revision control system (like git) that >>> depends on useful diffs to do code reviews. But sometimes the layout it >>> chooses is a little dumb. >>> >>> Stephen >>> >>> >>> On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff < >>> [email protected]> wrote: >>> >>>> Hi Craig, >>>> >>>> I'm attaching the latest object model diagram as discussed with the RAX >>>> team last night, Samuel and Eugene. Note that we don't necessarily have >>>> HP's blessing on this model yet, nor do we have Neutron core developer buy >>>> in. But in any case, here it is. >>>> >>>> Also, I think the #openstack-lbaas channel is a great idea! >>>> >>>> Stephen >>>> >>>> >>>> On Wed, May 14, 2014 at 9:05 AM, Craig Tracey <[email protected]>wrote: >>>> >>>>> Hi all, >>>>> >>>>> From what I heard last night, it sounds like there has been some >>>>> consensus achieved around the LBaaS object model. Unfortunately, I missed >>>>> this ad-hoc conversation. Is someone capturing this information and/or >>>>> perhaps posting to the list? someplace else? >>>>> >>>>> On a related note, does it make sense to create an lbaas IRC topic >>>>> channel? #openstack-lbaas? Just thinking that a dedicated channel might >>>>> help to make the weekly meetings more productive with less crosstalk. >>>>> Thoughts? >>>>> >>>>> Best, >>>>> Craig >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Stephen Balukoff >>>> Blue Box Group, LLC >>>> (800)613-4305 x807 >>>> >>> >>> >>> >>> -- >>> Stephen Balukoff >>> Blue Box Group, LLC >>> (800)613-4305 x807 >>> >> >> >> >> -- >> Stephen Balukoff >> Blue Box Group, LLC >> (800)613-4305 x807 >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
