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 <sbaluk...@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 > <sbaluk...@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 <sbaluk...@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 <cr...@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@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@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