[openstack-dev] [neutron][policy] Group-based Policy next steps
Stephen Wong
stephen.kf.wong at gmail.com
Thu Sep 11 17:45:18 UTC 2014
I agree with Kevin. Like in Juno, we as a subteam will be shooting for
option 1 (again) for Kilo - ideally we can land in Kilo, and we will work
closely with the community to try to accomplish that. In the meantime, we
need to have a repo to iterate our implementations, build package (Juno
based) to early adopters, and be as transparent as if the code is on
gerrit. With option 2 never picking up momentum when Bob suggested it on
the ML, option 3 being more like an idea discussed by several cores during
the mid-cycle meetup, and option 4 is currently on holding pattern without
any detail but tons of concern raised on ML --- option 5 (stackforge) seems
like the best available option at this point.
Thanks,
- Stephen
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/2c326176/attachment.html>
More information about the OpenStack-dev
mailing list