FWaas is typically classified to L4-L7. But if they are developed standalone, it would be very difficult for implementing with a distributed manner. For example, with W-E traffic control in DVR mode, we can't rely on a external python client rest api call, the policy execution module must be loaded as the L3 agent extension, or another service-policy agent in the compute node.
My suggestion is that starting with LB and VPN as a trial, which can never be distributed. FW is very tightly coupled with L3, so leaving it for discuss some time later may be more smooth. On Wed, Nov 19, 2014 at 6:31 AM, Mark McClain <[email protected]> wrote: > All- > > Over the last several months, the members of the Networking Program have > been discussing ways to improve the management of our program. When the > Quantum project was initially launched, we envisioned a combined service > that included all things network related. This vision served us well in the > early days as the team mostly focused on building out layers 2 and 3; > however, we’ve run into growth challenges as the project started building > out layers 4 through 7. Initially, we thought that development would float > across all layers of the networking stack, but the reality is that the > development concentrates around either layer 2 and 3 or layers 4 through 7. > In the last few cycles, we’ve also discovered that these concentrations have > different velocities and a single core team forces one to match the other to > the detriment of the one forced to slow down. > > Going forward we want to divide the Neutron repository into two separate > repositories lead by a common Networking PTL. The current mission of the > program will remain unchanged [1]. The split would be as follows: > > Neutron (Layer 2 and 3) > - Provides REST service and technology agnostic abstractions for layer 2 and > layer 3 services. > > Neutron Advanced Services Library (Layers 4 through 7) > - A python library which is co-released with Neutron > - The advance service library provides controllers that can be configured to > manage the abstractions for layer 4 through 7 services. > > Mechanics of the split: > - Both repositories are members of the same program, so the specs repository > would continue to be shared during the Kilo cycle. The PTL and the drivers > team will retain approval responsibilities they now share. > - The split would occur around Kilo-1 (subject to coordination of the Infra > and Networking teams). The timing is designed to enable the proposed REST > changes to land around the time of the December development sprint. > - The core team for each repository will be determined and proposed by Kyle > Mestery for approval by the current core team. > - The Neutron Server and the Neutron Adv Services Library would be co-gated > to ensure that incompatibilities are not introduced. > - The Advance Service Library would be an optional dependency of Neutron, so > integrated cross-project checks would not be required to enable it during > testing. > - The split should not adversely impact operators and the Networking program > should maintain standard OpenStack compatibility and deprecation cycles. > > This proposal to divide into two repositories achieved a strong consensus at > the recent Paris Design Summit and it does not conflict with the current > governance model or any proposals circulating as part of the ‘Big Tent’ > discussion. > > Kyle and mark > > [1] > https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
