13 messages in net.launchpad.lists.openstackRe: [Openstack] [openstack-dev] Annou...| From | Sent On | Attachments |
|---|---|---|
| Eugene Kirpichov | Jul 24, 2012 6:32 pm | |
| Angus Salkeld | Jul 24, 2012 7:51 pm | |
| Dan Wendlandt | Jul 24, 2012 8:30 pm | |
| Eugene Kirpichov | Jul 24, 2012 8:37 pm | |
| Thierry Carrez | Jul 25, 2012 1:54 am | |
| Eugene Kirpichov | Jul 25, 2012 1:33 pm | |
| Youcef Laribi | Jul 25, 2012 1:54 pm | |
| Dan Wendlandt | Jul 25, 2012 6:21 pm | |
| Dan Wendlandt | Jul 25, 2012 6:30 pm | |
| Angus Salkeld | Jul 25, 2012 7:51 pm | |
| Youcef Laribi | Jul 25, 2012 9:57 pm | |
| Dan Wendlandt | Jul 25, 2012 10:22 pm | |
| Eugene Kirpichov | Aug 2, 2012 11:55 am |
| Subject: | Re: [Openstack] [openstack-dev] Announcing proof-of-concept Load Balancing as a Service project | |
|---|---|---|
| From: | Dan Wendlandt (da...@nicira.com) | |
| Date: | Jul 25, 2012 6:21:41 pm | |
| List: | net.launchpad.lists.openstack | |
On Wed, Jul 25, 2012 at 1:33 PM, Eugene Kirpichov <ekir...@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 : open...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp