<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS deals with L3 connectivity but belongs in advanced services. Where does Edge-VPN work belong? We need a broader definition for advanced services area.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>—Hanif. </div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"Paul Michali (pcm)" <<a href="mailto:pcm@cisco.com">pcm@cisco.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, November 18, 2014 at 4:08 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
On Nov 18, 2014, at 6:36 PM, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
<div>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Mark, Kyle,
<div><br>
</div>
<div>What is the strategy for tracking the progress and all the details about this initiative? Blueprint spec, wiki page, or something else?</div>
<div><br>
</div>
<div>One thing I personally found useful about the spec approach adopted in [1], was that we could quickly and effectively incorporate community feedback; having said that I am not sure that the same approach makes sense here, hence the question.</div>
<div><br>
</div>
<div>Also, what happens for experimental efforts that are neither L2-3 nor L4-7 (e.g. TaaS or NFV related ones?), but they may still benefit from this decomposition (as it promotes better separation of responsibilities)? Where would they live? I am not sure
we made any particular progress of the incubator project idea that was floated a while back.</div>
</div>
</blockquote>
<div><br>
</div>
Would it make sense to define the advanced services repo as being for services that are beyond basic connectivity and routing? For example, VPN can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion as to what’s in and what’s out.</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div>PCM (Paul Michali)</div>
<div><br>
</div>
<div>MAIL …..…. <a href="mailto:pcm@cisco.com">pcm@cisco.com</a></div>
<div>IRC ……..… pc_m (<a href="http://irc.freenode.com">irc.freenode.com</a>)</div>
<div>TW ………... @pmichali</div>
<div>GPG Key … 4525ECC253E31A83</div>
<div>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83</div>
</div>
<div><br>
</div>
</div>
</div>
<div><br class="webkit-block-placeholder">
</div>
<div></div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,</div>
<div>Armando</div>
<div><br>
</div>
<div>[1] <a href="https://review.openstack.org/#/c/134680/" target="_blank">https://review.openstack.org/#/c/134680/</a></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 18 November 2014 15:32, Doug Wiegley <span dir="ltr">
<<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>Hi,</div>
<span class="">
<div><br>
</div>
<div>> so the specs repository would continue to be shared during the Kilo cycle.</div>
<div><br>
</div>
</span>
<div>One of the reasons to split is that these two teams have different priorities and velocities. Wouldn’t that be easier to track/manage as separate launchpad projects and specs repos, irrespective of who is approving them?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>doug</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<blockquote type="cite">
<div>
<div class="h5">
<div>On Nov 18, 2014, at 10:31 PM, Mark McClain <<a href="mailto:mark@mcclain.xyz" target="_blank">mark@mcclain.xyz</a>> wrote:</div>
<br>
</div>
</div>
<div>
<div>
<div class="h5">
<div style="word-wrap:break-word">All-<br>
<br>
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.<br>
<br>
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:<br>
<br>
Neutron (Layer 2 and 3)<br>
- Provides REST service and technology agnostic abstractions for layer 2 and layer 3 services.<br>
<br>
Neutron Advanced Services Library (Layers 4 through 7)<br>
- A python library which is co-released with Neutron<br>
- The advance service library provides controllers that can be configured to manage the abstractions for layer 4 through 7 services.<br>
<br>
Mechanics of the split:<br>
- 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. <br>
- 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.<br>
- The core team for each repository will be determined and proposed by Kyle Mestery for approval by the current core team.<br>
- The Neutron Server and the Neutron Adv Services Library would be co-gated to ensure that incompatibilities are not introduced.<br>
- 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.<br>
- The split should not adversely impact operators and the Networking program should maintain standard OpenStack compatibility and deprecation cycles.<br>
<br>
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.<br>
<br>
Kyle and mark<br>
<br>
[1] <a href="https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml" target="_blank">https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml</a></div>
</div>
</div>
<span class="">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</span></div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>