Open Stack

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 <craig at craigtracey.com> 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 <sbalukoff at bluebox.net>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 <sbalukoff at bluebox.net
>> > 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 <
>>> sbalukoff at bluebox.net> 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 <craig at craigtracey.com>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
>>>>> OpenStack-dev at lists.openstack.org
>>>>> 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
>> 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
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140514/6f5c7bfc/attachment.html>