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
<kuk...@noironetworks.com <mailto:kuk...@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
<jaypi...@gmail.com <mailto:jaypi...@gmail.com>
<mailto:jaypi...@gmail.com <mailto:jaypi...@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
