Open Stack

On 9/9/14, 7:51 PM, Jay Pipes wrote:
> On 09/09/2014 06:57 PM, Kevin Benton wrote:
>> Hi Jay,
>>
>> 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.
>
> OK, thanks for the explanation Kevin, that helps!
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.

-Bob
>
> Best,
> -jay
>
>> On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>> wrote:
>>
>>     On 09/04/2014 12:07 AM, Sumit Naiksatam wrote:
>>
>>         Hi,
>>
>>         There's been a lot of lively discussion on GBP a few weeks back
>>         and we
>>         wanted to drive forward the discussion on this a bit more. As 
>> you
>>         might imagine, we're excited to move this forward so more 
>> people can
>>         try it out.  Here are the options:
>>
>>         * Neutron feature branch: This presumably allows the GBP feature
>>         to be
>>         developed independently, and will perhaps help in faster 
>> iterations.
>>         There does seem to be a significant packaging issue [1] with 
>> this
>>         approach that hasn’t been completely addressed.
>>
>>         * Neutron-incubator: This allows a path to graduate into
>>         Neutron, and
>>         will be managed by the Neutron core team. That said, the 
>> proposal is
>>         under discussion and there are still some open questions [2].
>>
>>         * Stackforge: This allows the GBP team to make rapid and 
>> iterative
>>         progress, while still leveraging the OpenStack infra. It also
>>         provides
>>         option of immediately exposing the existing implementation to 
>> early
>>         adopters.
>>
>>         Each of the above options does not preclude moving to the other
>>         at a later time.
>>
>>         Which option do people think is more preferable?
>>
>>         (We could also discuss this in the weekly GBP IRC meeting on
>>         Thursday:
>> https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy 
>> <https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy>)
>>
>>         Thanks!
>>
>>         [1]
>> http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html
>> <http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html>
>>         [2]
>> http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html
>> <http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html>
>>
>>
>>     Hi all,
>>
>>     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.
>>
>>     If this is the case, how would the stackforge GBP project work if it
>>     wasn't a fork of Neutron in its entirety?
>>
>>     Just curious,
>>     -jay
>>
>>
>>     _________________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.__org
>>     <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> -- 
>> Kevin Benton
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev