<div dir="ltr">Being in the incubator won't help with this if it's a different repo as well.</div><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 class=""><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 class="HOEnZb"><div class="h5"><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/__<u></u>wiki/Meetings/Neutron_Group___<u></u>Policy</a> <<a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy" target="_blank">https://wiki.openstack.org/<u></u>wiki/Meetings/Neutron_Group_<u></u>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/__<u></u>pipermail/openstack-dev/2014-_<u></u>_August/044283.html</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>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/__<u></u>pipermail/openstack-dev/2014-_<u></u>_August/043577.html</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>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>
______________________________<u></u>___________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.<u></u>__org<br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><br>
<br>
<br>
<br>
<br>
-- <br>
Kevin Benton<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>