Open Stack

Advanced services like load balancing, VPNs, and firewalls require internal access to L2 and L3 resources to provide a cohesive and efficient experience for both tenants and deployers.   These are services that we as a team have been discussing for a long time - it has just taken time to get to this point (see https://wiki.openstack.org/wiki/Projects/CoreApplication/Quantum).  Turning the services into distinct projects would be counterproductive as it requires the development of additional REST, RPC, code level APIs devoted specifically interoperability.  The process would create a significant drag on the development of each project while increasing the complexity of deployments.

Our plan for managing the development of advance services will follow the same sub-team model that we used during Grizzly.  From the PTL perspective, our open sub-team format produces better code reviews, facilitates communication, and makes the project more efficient.  For Havana, we've added Firewall and VPN sub-teams (Load Balancing existed during Grizzly).  So far, the teams have been able to rapidly iterate over specifications unique to their extension while collaborating on common initiatives that benefit the entire community. 

I'm excited about the progress the we've made and what's in store for the future.

mark

On Apr 30, 2013, at 2:41 PM, Tom Creighton <tom.creighton at RACKSPACE.COM> wrote:

> Eugene/All:
> 
> I agree that the current advanced services need to be tightly coupled with Core Networking from a development perspective.  However, the collection of advanced services (fw, vpn, lb) has grown to a size that is comparable to Core Networking itself.  Trying to maintain all of it under one project and one PTL will, (a) burn out the PTL, (b) impact the speed of development, and (c) prevent each group from focusing on their respective charters.  This is exactly why networking was stripped out of Nova; it was getting to big!  :-)
> 
> Kind regards,
> 
> Tom Creighton
> 
> On Apr 30, 2013, at 3:03 AM, Eugene Nikanorov <enikanorov at mirantis.com> wrote:
> 
>> Folks,
>> 
>> Since grizzly Quantum consists of 2 parts: core and "advanced services", where core is L2+L3 and advanced services are lbaas, vpnaas, fwaas, etc. 
>> So first of all, it would make more sense to have "networking services" project rather than just LBaaS.
>> Second, it might be not a good time to separate lbaas out of quantum in havana because there are several key features that are not yet implemented (service insertion, service chaining). 
>> Project separation requires lots of additional maintenance work as well as interaction with "mother" project. 
>> Once those key features are implemented and communication APIs are stabilized project separation will take much less effort.
>> 
>> E.g. my opinion is that it would be worth separating LBaaS/adv. services once they get more mature.
>> 
>> Thanks,
>> Eugene.
>> 
>> 
>> 
>> On Tue, Apr 30, 2013 at 5:15 AM, Raja Srinivasan <Raja.Srinivasan at riverbed.com> wrote:
>> I agree. This should be considered as a separate project by itself. 
>> 
>> 
>> We seem to be focusing on Load Balancing as a Service offering, but I think there is a larger role for ADCs in general in both the public and private clouds.  Is that also within the preview of this project?  I am also curious to see how this would all feed into the ceilometer project for tracking usage.
>> 
>> 
>> 
>> 
>> 
>> Thanks & Regards
>> 
>> Raja Srinivasan
>> 
>> (408) 598-1175
>> 
>> Raja.Srinivasan at Riverbed.com
>> 
>> 
>> 
>> From: Michael Still [mailto:mikal at stillhq.com] 
>> Sent: Monday, April 29, 2013 6:03 PM
>> 
>> 
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [Quantum][LBaaS] LBaaS development plan for Havana
>> 
>> 
>> 
>> On Tue, Apr 30, 2013 at 10:52 AM, Russell Bryant <rbryant at redhat.com> wrote:
>> 
>> So ... speaking of LBaaS future plans ... it seems really odd to have
>> this in the project formerly known as Quantum, err, OpenStack
>> Networking.  It honestly seems like something I would have expected to
>> be in its own project.  Feel free to send me off to read previous
>> discussions on this if needed.
>> 
>> Does anyone else have concerns about this?
>> 
>> 
>> 
>> Certainly there's a push in nova to become as simple as possible -- moving nova-network, nova-volumes and nova-baremetal into separate projects are all examples. I'd like to see a test something along the lines of "is this absolutely needed by a majority of deployments?". If it isn't perhaps it should be its own project?
>> 
>> 
>> 
>> Now, perhaps that's true of LBaaS, but I'd like to be educated here if possible.
>> 
>> 
>> 
>> Michael
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev