On Wed, Jul 25, 2012 at 1:33 PM, Eugene Kirpichov <ekirpic...@gmail.com>wrote:
> > >>> > >>> Another question we have is if this should be a standalone module or a > >>> Quantum plugin… > > > > > > Based on discussions during the PPB meeting about quantum becoming core, > > there was a push for having a single network service and API, which would > > tend to suggest it being a sub-component of Quantum that is independently > > loadable. I also tend to think that its likely to be a common set of > > developers working across all such networking functionality, so it > wouldn't > > seem like keeping different core-dev teams, repos, tarballs, docs, etc. > > probably doesn't make sense. I think this is generally inline with the > plan > > of allowing Quantum to load additional portions of the API as needed for > > additional services like LB, WAN-bridging, but this is probably a call > for > > the PPB in general. > So, if I'm understanding correctly, you're suggesting LBaaS to be > usable in 2 ways: > * Independently > * As a quantum plugin > This is where naming gets tricky :) I would tend to think of LBaaS a service as an independently loadable component within Quantum, which is to say, your choice of a LBaaS back-end would be completely independent of your choice of a "core" Quantum plugin. As a result, a provider could choose to expose only the load-balancer API to tenants, if that is what that operator wanted. I'm not sure if this is the same as what you suggest. Either way, I think the right thing here is to focus on what different deployment scenarios we see this being used in, then we can figure out how tightly coupled it should be to the man quantum service. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp