Open Stack

On Wed, Jul 25, 2012 at 1:33 PM, Eugene Kirpichov <ekirpichov at 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120725/ce9e9bfd/attachment.html>