[openstack-dev] [Neutron][LBaaS] Updated Object Model?

Craig Tracey craig at craigtracey.com
Wed May 14 22:04:53 UTC 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140514/92992894/attachment.html>


More information about the OpenStack-dev mailing list