<div dir="ltr">Hi Jay,<div><br></div><div>The main component that won't work without direct integration is enforcing policy on calls directly to Neutron and calls between the plugins inside of Neutron. However, that's only one component of GBP. All of the declarative abstractions, rendering of policy, etc can be experimented with here in the stackforge project until the incubator is figured out.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.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="">On 09/04/2014 12:07 AM, Sumit Naiksatam wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
There's been a lot of lively discussion on GBP a few weeks back 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 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 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 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 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 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>)<br>
<br>
Thanks!<br>
<br>
[1] <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] <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>
</blockquote>
<br></span>
Hi all,<br>
<br>
IIRC, Kevin was saying to me in IRC that GBP really needs to live in-tree due to it needing access to various internal plugin points and to be able to call across different plugin layers/drivers inside of Neutron.<br>
<br>
If this is the case, how would the stackforge GBP project work if it wasn't a fork of Neutron in its entirety?<br>
<br>
Just curious,<br>
-jay<div class="HOEnZb"><div class="h5"><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>