[openstack-dev] [neutron][policy] Group-based Policy next steps
Mandeep Dhami
dhami at noironetworks.com
Thu Sep 11 17:23:14 UTC 2014
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).
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.
Regards,
Mandeep
----
On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton <blak111 at gmail.com> wrote:
> Thanks. This is good writeup.
>
> >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 :-( .
>
> 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.
>
> >Does the above make some sense? What have I missed?
>
> Option 1 is great, but I don't see how the same thing that happened in
> Juno would be avoided.
>
> 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.
>
> Option 3 sounded like it brought up a lot of tooling (gerrit) issues with
> regard to how the merging workflow would work.
>
> Option 4 is unknown until the incubator details are hashed out.
>
> 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.
>
>
>
>
> On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura <kukura at noironetworks.com>
> wrote:
>
>>
>> On 9/10/14, 6:54 PM, Kevin Benton wrote:
>>
>> Being in the incubator won't help with this if it's a different repo as
>> well.
>>
>> Agreed.
>>
>> 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:
>>
>> 1) Merge the GBP patches to the neutron repo early in Kilo and iterate,
>> just like we had planned for Juno ;-) .
>>
>> 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.
>>
>> 3) Like 1, but merge to a feature branch in the neutron repo and iterate
>> there.
>>
>> 4) Develop in an official neutron-incubator repo, with neutron core
>> reviews of each GBP patch.
>>
>> 5) Develop in StackForge, without neutron core reviews.
>>
>>
>> Here's how I see these options in terms of the various considerations
>> that have come up during this discussion:
>>
>> * 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.
>>
>> * 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.
>>
>> * 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.
>>
>> * 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.
>>
>> * 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.
>>
>> * 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.
>>
>> * 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.
>>
>>
>> Does the above make some sense? What have I missed?
>>
>> 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 :-( . 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.
>>
>> -Bob
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/b8242ad5/attachment.html>
More information about the OpenStack-dev
mailing list