<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I agree with Kevin. Any option in-tree or in-incubator would need core review time, and they are already oversubscribed with nova parity issues (for Juno). So the only option to continue collaboration on experimenting with policy based networking on current openstack is on stackforge (option 5).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the summary is: We develop in stackforge for Juno code, and that we should keep our options open and review this as a community again during the Kilo conference.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Mandeep</div><div class="gmail_default" style="font-size:small">----</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks. This is good writeup.<div><br></div><div><span class=""><div>><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">Of course this all assumes there is consensus that we should proceed with GBP, that we should continue by iterating the currently proposed design and code, and that GBP should eventually become part of Neutron. These assumptions may still be the real issues</span><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"> :-( </span><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">.</span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div></span><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">Unfortunately I think this is the real root cause. Most of the people that worked on GBP definitely want to see it merged into Neutron and is in general agreement there. However, some of the other cores disagreed and now GBP is sitting in limbo. IIUC, this thread was started to just get GBP to some location where it can be developed on and tested that isn't a big string of rejected gerrit patches. </span></div></div><span class=""><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">></span><span style="font-family:arial,sans-serif;font-size:13.333333015441895px">Does the above make some sense? What have I missed?</span><span style="font-family:arial,sans-serif;font-size:13.333333015441895px"> </span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div></span><div><font face="arial, sans-serif">Option 1 is great, but I don't see how the same thing that happened in Juno would be avoided.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 2 is also good, but that idea didn't seem to catch on. If this option is on the table, this seems like the best way to go.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 3 sounded like it brought up a lot of tooling (gerrit) issues with regard to how the merging workflow would work. </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 4 is unknown until the incubator details are hashed out.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 5 is stackforge. I see this as a better place just to do what is already being done right now. You're right that patches would occur without core reviewers, but that's essentially what's happening now since nothing is getting merged. </font></div><div><font face="arial, sans-serif"><br></font></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<br>
<div>On 9/10/14, 6:54 PM, Kevin Benton
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Being in the incubator won't help with this if it's
a different repo as well.</div>
</blockquote></span>
Agreed. <br>
<br>
Given the requirement for GBP to intercept API requests, the
potential couplings between policy drivers, ML2 mechanism drivers,
and even service plugins (L3 router), and the fact Neutron doesn't
have a stable [service] plugin API, along with the goal to
eventually merge GBP into Neutron, I'd rank the options as follows
in descending order:<br>
<br>
1) Merge the GBP patches to the neutron repo early in Kilo and
iterate, just like we had planned for Juno<span><span> ;-) </span></span>.<br>
<br>
2) Like 1, but with the code initially in a "preview" subtree to
clarify its level of stability and support, and to facilitate
packaging it as an optional component.<br>
<br>
3) Like 1, but merge to a feature branch in the neutron repo and
iterate there.<br>
<br>
4) Develop in an official neutron-incubator repo, with neutron core
reviews of each GBP patch.<br>
<br>
5) Develop in StackForge, without neutron core reviews.<br>
<br>
<br>
Here's how I see these options in terms of the various
considerations that have come up during this discussion:<br>
<br>
* Options 1, 2 and 3 most easily support whatever coupling is needed
with the rest of Neutron. Options 4 and 5 would sometimes require
synchronized changes across repos since dependencies aren't in terms
of stable interfaces. <br>
<br>
* Options 1, 2 and 3 provide a clear path to eventually graduate GBP
into a fully supported Neutron feature, without loss of git history.
Option 4 would have some hope of eventually merging into the neutron
repo due to the code having already had core reviews. With option 5,
reviewing and merging a complete GBP implementation from StackForge
into the neutron repo would be a huge effort, with significant risk
that reviewers would want design changes not practical to make at
that stage.<br>
<br>
* Options 1 and 2 take full advantage of existing review, CI,
packaging and release processes and mechanisms. All the other
options require extra work to put these in place.<br>
<br>
* Options 1 and 2 can easily make GBP consumable by early adopters
through normal channels such as devstack and OpenStack
distributions. The other options all require the operator or the
packager to pull GBP code from a different source than the base
Neutron code.<br>
<br>
* Option 1 relies on the historical understanding that new Neutron
extension APIs are not initially considered stable, and incompatible
changes can occur in future releases. Options 2, 3 and 4 make this
explicit. Option 5 really has nothing to do with Neutron.<br>
<br>
* Option 5 allows rapid iteration by the GBP team, without waiting
for core review. This is essential during experimentation and
prototyping, but at least some participants consider the GBP
implementation to be well beyond that phase.<br>
<br>
* Options 3, 4, and 5 potentially decouple the GBP release schedule
from the Neutron release schedule. With options 1 or 2, GBP
snapshots would be included in all normal Neutron releases. With any
of the options, the GBP team, vendors, or distributions would be
able to back-port arbitrary snapshots of GBP to a branch off the
stable/juno branch (in the neutron repo itself or in a clone) to
allow early adopters to use GBP with Juno-based OpenStack
distributions.<br>
<br>
<br>
Does the above make some sense? What have I missed? <br>
<br>
Of course this all assumes there is consensus that we should proceed
with GBP, that we should continue by iterating the currently
proposed design and code, and that GBP should eventually become part
of Neutron. These assumptions may still be the real issues<span><span> :-( </span></span>. If we can't
agree on whether GBP is in an experimentation/rapid-prototyping
phase vs. an almost-ready-to-beta-test phase, I don't see how can we
get consensus on the next steps for its development.<br>
<br>
-Bob<div><div><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 10, 2014 at 7:22 AM, Robert
Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 9/9/14, 7:51 PM, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/09/2014 06:57 PM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jay,<br>
<br>
The main component that won't work without direct
integration is<br>
enforcing policy on calls directly to Neutron and
calls between the<br>
plugins inside of Neutron. However, that's only one
component of GBP.<br>
All of the declarative abstractions, rendering of
policy, etc can be<br>
experimented with here in the stackforge project until
the incubator is<br>
figured out.<br>
</blockquote>
<br>
OK, thanks for the explanation Kevin, that helps!<br>
</blockquote>
</span>
I'll add that there is likely to be a close coupling between
ML2 mechanism drivers and corresponding GBP policy drivers
for some of the back-end integrations. These will likely
share local state such as connections to controllers, and
may interact with each other as part of processing core and
GBP API requests. Development, review, and packaging of
these would be facilitated by having them on the same branch
in the same repo, but its probably not absolutely necessary.<br>
<br>
-Bob
<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br>
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>>
wrote:<br>
<br>
On 09/04/2014 12:07 AM, Sumit Naiksatam wrote:<br>
<br>
Hi,<br>
<br>
There's been a lot of lively discussion on
GBP a few weeks back<br>
and we<br>
wanted to drive forward the discussion on
this a bit more. As you<br>
might imagine, we're excited to move this
forward so more people can<br>
try it out. Here are the options:<br>
<br>
* Neutron feature branch: This presumably
allows the GBP feature<br>
to be<br>
developed independently, and will perhaps
help in faster iterations.<br>
There does seem to be a significant
packaging issue [1] with this<br>
approach that hasn’t been completely
addressed.<br>
<br>
* Neutron-incubator: This allows a path to
graduate into<br>
Neutron, and<br>
will be managed by the Neutron core team.
That said, the proposal is<br>
under discussion and there are still some
open questions [2].<br>
<br>
* Stackforge: This allows the GBP team to
make rapid and iterative<br>
progress, while still leveraging the
OpenStack infra. It also<br>
provides<br>
option of immediately exposing the existing
implementation to early<br>
adopters.<br>
<br>
Each of the above options does not preclude
moving to the other<br>
at a later time.<br>
<br>
Which option do people think is more
preferable?<br>
<br>
(We could also discuss this in the weekly
GBP IRC meeting on<br>
Thursday:<br>
<a href="https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy" target="_blank">https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy</a>
<<a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy" target="_blank">https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy</a>>)<br>
<br>
Thanks!<br>
<br>
[1]<br>
<a href="http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html" target="_blank">http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html</a>><br>
[2]<br>
<a href="http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html" target="_blank">http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html</a>><br>
<br>
<br>
Hi all,<br>
<br>
IIRC, Kevin was saying to me in IRC that GBP
really needs to live<br>
in-tree due to it needing access to various
internal plugin points<br>
and to be able to call across different plugin
layers/drivers inside<br>
of Neutron.<br>
<br>
If this is the case, how would the stackforge
GBP project work if it<br>
wasn't a fork of Neutron in its entirety?<br>
<br>
Just curious,<br>
-jay<br>
<br>
<br>
_________________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.__org" target="_blank">OpenStack-dev@lists.openstack.__org</a><br>
<mailto:<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>
<<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>
<br>
<br>
<br>
-- <br>
Kevin Benton<br>
<br>
<br>
_______________________________________________<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>
<br>
</blockquote>
<br>
_______________________________________________<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>
</blockquote>
<br>
<br>
_______________________________________________<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>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Kevin Benton</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>
</div></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>