Open Stack

Being in the incubator won't help with this if it's a different repo as
well.

On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura <kukura at noironetworks.com>
wrote:

>
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/d1411732/attachment.html>