13 messages in net.launchpad.lists.openstackRe: [Openstack] Announcing proof-of-c...| 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] Announcing proof-of-concept Load Balancing as a Service project | |
|---|---|---|
| From: | Thierry Carrez (thie...@openstack.org) | |
| Date: | Jul 25, 2012 1:54:05 am | |
| List: | net.launchpad.lists.openstack | |
Dan Wendlandt wrote:
On 24/07/12 18:33 -0700, Eugene Kirpichov wrote:
We at Mirantis have had a number of clients request functionality to control various load balancer devices (software and hardware) via an OpenStack API and horizon. So, in collaboration with Cisco OpenStack team and a number of other community members, we’ve started socializing the blueprints for an elastic load balancer API service. At this point we’d like to share where we are and would very much appreciate anyone participate and provide input.
Yes, I definitely think LB is one of the key items that we'll want to tackle
during Grizzly in terms of L4-L7 services.
Yes, LB sounds like the first service to implement in the "utility network services" direction.
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.
The sub-component approach would have my preference. It sounds like a natural advanced network service to provide within Quantum.
-- Thierry Carrez (ttx) Release Manager, OpenStack
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : open...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp