Open Stack

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 <mailto: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>
>             <mailto: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
>             <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
>             <mailto: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
>         <mailto: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
>     <mailto: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/0f1c7474/attachment.html>