Hi Stephen:
* 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.) When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id & listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? * 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.) Yes please, could you explain on the ML! Thanks, Vijay V. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Wednesday, May 14, 2014 11:02 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? 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<mailto: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<mailto: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<mailto: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<mailto: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<tel:%28800%29613-4305%20x807> -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807<tel:%28800%29613-4305%20x807> -- 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
