Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-11 Thread Robert Kukura


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 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-11 Thread Kevin Benton
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 kuk...@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 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-11 Thread Mandeep Dhami
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 blak...@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 kuk...@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 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-11 Thread Stephen Wong
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 blak...@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 kuk...@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 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-10 Thread Robert Kukura


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 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
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
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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-10 Thread Kevin Benton
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 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 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
 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
 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



 ___
 OpenStack-dev mailing list
 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


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Sumit Naiksatam
On Sat, Sep 6, 2014 at 9:54 AM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:

 Good discussion.

 Based on this I think we should get started on the stackforge right away.

 Sumit - It would be great if you get started on the StackForge soon. We
 have a few changes that needs to be submitted and have been holding up.


The stackforge repo has been created:
https://github.com/stackforge/group-based-policy


 On Fri, Sep 5, 2014 at 8:08 AM, Mohammad Banikazemi m...@us.ibm.com wrote:

 I can only see the use of a separate project for Group Policy as a
 tactical and temporary solution. In my opinion, it does not make sense to
 have the Group Policy as a separate project outside Neutron (unless the new
 project is aiming to replace Neutron and I do not think anybody is
 suggesting that). In this regard, Group Policy is not similar to Advanced
 Services such as FW and LB.

 So, using StackForge to get things moving again is fine but let us keep
 in mind (and see if we can agree on) that we want to have the Group Policy
 abstractions as part of OpenStack Networking (when/if it proves to be a
 valuable extension to what we currently have). I do not want to see our
 decision to make things moving quickly right now prevent us from achieving
 that goal. That is why I think the other two approaches (from the little I
 know about the incubator option, and even littler I know about the feature
 branch option) may be better options in the long run.

 If I understand it correctly some members of the community are actively
 working on these options (that is, the incubator and the Neutron feature
 branch options) . In order to make a better judgement as to how to proceed,
 it would be very helpful if we get a bit more information on these two
 options and their status here on this mailing list.

 Mohammad



 [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05
 AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin
 Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki
 page with many uncertainties. Use StackForge to make progre

 From: Kevin Benton blak...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 09/05/2014 04:31 AM
 Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next
 steps
 --



 Tl;dr - Neutron incubator is only a wiki page with many uncertainties.
 Use StackForge to make progress and re-evaluate when the incubator exists.


 I also agree that starting out in StackForge as a separate repo is a
 better first step. In addition to the uncertainty around packaging and
 other processes brought up by Mandeep, I really doubt the Neutron incubator
 is going to have the review velocity desired by the group policy
 contributors. I believe this will be the case based on the Neutron
 incubator patch approval policy in conjunction with the nature of the
 projects it will attract.

 Due to the requirement for two core +2's in the Neutron incubator, moving
 group policy there is hardly going to do anything to reduce the load on the
 Neutron cores who are in a similar overloaded position as the Nova
 cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
 incubator receive even less core attention than the main repo simply
 because their location outside of openstack/neutron will be a good reason
 to treat them with a lower priority.

 If you combine that with the fact that the incubator is designed to house
 all of the proposed experimental features to Neutron, there will be a very
 high volume of patches constantly being proposed to add new features, make
 changes to features, and maybe even fix bugs in those features. This new
 demand for reviewers will not be met by the existing core reviewers because
 they will be busy with refactoring, fixing, and enhancing the core Neutron
 code.

 Even ignoring the review velocity issues, I see very little benefit to
 GBP starting inside of the Neutron incubator. It doesn't guarantee any
 packaging with Neutron and Neutron code cannot reference any incubator
 code. It's effectively a separate repo without the advantage of being able
 to commit code quickly.

 There is one potential downside to not immediately using the Neutron
 incubator. If the Neutron cores decide that all features must live in the
 incubator for at least 2 cycles regardless of quality or usage in
 deployments, starting outside in a StackForge project would delay the start
 of the timer until GBP makes it into the incubator. However, this can be
 considered once the incubator actually exists and starts accepting
 submissions.

 In summary, I think GBP should move to a StackForge project as soon as
 possible so development can progress. A transition to the Neutron incubator
 can be evaluated once it actually becomes something more than a wiki page.


 1.
 *http://lists.openstack.org/pipermail/openstack-dev/2014

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Jay Pipes

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)

Thanks!

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
[2] 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Kevin Benton
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.

On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes 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)

 Thanks!

 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-
 August/044283.html
 [2] 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
 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


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Jay Pipes

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!

Best,
-jay


On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes 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
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
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


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Baohua Yang
Agree.
It's necessary for neutron to have GBP, and we can certainly utilize
stackforge to help improve it.


On Fri, Sep 5, 2014 at 11:08 PM, Mohammad Banikazemi m...@us.ibm.com wrote:

 I can only see the use of a separate project for Group Policy as a
 tactical and temporary solution. In my opinion, it does not make sense to
 have the Group Policy as a separate project outside Neutron (unless the new
 project is aiming to replace Neutron and I do not think anybody is
 suggesting that). In this regard, Group Policy is not similar to Advanced
 Services such as FW and LB.

 So, using StackForge to get things moving again is fine but let us keep in
 mind (and see if we can agree on) that we want to have the Group Policy
 abstractions as part of OpenStack Networking (when/if it proves to be a
 valuable extension to what we currently have). I do not want to see our
 decision to make things moving quickly right now prevent us from achieving
 that goal. That is why I think the other two approaches (from the little I
 know about the incubator option, and even littler I know about the feature
 branch option) may be better options in the long run.

 If I understand it correctly some members of the community are actively
 working on these options (that is, the incubator and the Neutron feature
 branch options) . In order to make a better judgement as to how to proceed,
 it would be very helpful if we get a bit more information on these two
 options and their status here on this mailing list.

 Mohammad



 [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05
 AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin
 Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki
 page with many uncertainties. Use StackForge to make progre

 From: Kevin Benton blak...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 09/05/2014 04:31 AM
 Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next
 steps
 --



 Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
 StackForge to make progress and re-evaluate when the incubator exists.


 I also agree that starting out in StackForge as a separate repo is a
 better first step. In addition to the uncertainty around packaging and
 other processes brought up by Mandeep, I really doubt the Neutron incubator
 is going to have the review velocity desired by the group policy
 contributors. I believe this will be the case based on the Neutron
 incubator patch approval policy in conjunction with the nature of the
 projects it will attract.

 Due to the requirement for two core +2's in the Neutron incubator, moving
 group policy there is hardly going to do anything to reduce the load on the
 Neutron cores who are in a similar overloaded position as the Nova
 cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
 incubator receive even less core attention than the main repo simply
 because their location outside of openstack/neutron will be a good reason
 to treat them with a lower priority.

 If you combine that with the fact that the incubator is designed to house
 all of the proposed experimental features to Neutron, there will be a very
 high volume of patches constantly being proposed to add new features, make
 changes to features, and maybe even fix bugs in those features. This new
 demand for reviewers will not be met by the existing core reviewers because
 they will be busy with refactoring, fixing, and enhancing the core Neutron
 code.

 Even ignoring the review velocity issues, I see very little benefit to GBP
 starting inside of the Neutron incubator. It doesn't guarantee any
 packaging with Neutron and Neutron code cannot reference any incubator
 code. It's effectively a separate repo without the advantage of being able
 to commit code quickly.

 There is one potential downside to not immediately using the Neutron
 incubator. If the Neutron cores decide that all features must live in the
 incubator for at least 2 cycles regardless of quality or usage in
 deployments, starting outside in a StackForge project would delay the start
 of the timer until GBP makes it into the incubator. However, this can be
 considered once the incubator actually exists and starts accepting
 submissions.

 In summary, I think GBP should move to a StackForge project as soon as
 possible so development can progress. A transition to the Neutron incubator
 can be evaluated once it actually becomes something more than a wiki page.


 1.
 *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html*
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html

 --
 Kevin Benton


 On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami *dh...@noironetworks.com*
 dh...@noironetworks.com wrote:


I agree. Also, as this does not preclude using the incubator when it
is ready

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-06 Thread Prasad Vellanki
Good discussion.

Based on this I think we should get started on the stackforge right away.

Sumit - It would be great if you get started on the StackForge soon. We
have a few changes that needs to be submitted and have been holding up.


On Fri, Sep 5, 2014 at 8:08 AM, Mohammad Banikazemi m...@us.ibm.com wrote:

 I can only see the use of a separate project for Group Policy as a
 tactical and temporary solution. In my opinion, it does not make sense to
 have the Group Policy as a separate project outside Neutron (unless the new
 project is aiming to replace Neutron and I do not think anybody is
 suggesting that). In this regard, Group Policy is not similar to Advanced
 Services such as FW and LB.

 So, using StackForge to get things moving again is fine but let us keep in
 mind (and see if we can agree on) that we want to have the Group Policy
 abstractions as part of OpenStack Networking (when/if it proves to be a
 valuable extension to what we currently have). I do not want to see our
 decision to make things moving quickly right now prevent us from achieving
 that goal. That is why I think the other two approaches (from the little I
 know about the incubator option, and even littler I know about the feature
 branch option) may be better options in the long run.

 If I understand it correctly some members of the community are actively
 working on these options (that is, the incubator and the Neutron feature
 branch options) . In order to make a better judgement as to how to proceed,
 it would be very helpful if we get a bit more information on these two
 options and their status here on this mailing list.

 Mohammad



 [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05
 AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin
 Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki
 page with many uncertainties. Use StackForge to make progre

 From: Kevin Benton blak...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 09/05/2014 04:31 AM
 Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next
 steps
 --



 Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
 StackForge to make progress and re-evaluate when the incubator exists.


 I also agree that starting out in StackForge as a separate repo is a
 better first step. In addition to the uncertainty around packaging and
 other processes brought up by Mandeep, I really doubt the Neutron incubator
 is going to have the review velocity desired by the group policy
 contributors. I believe this will be the case based on the Neutron
 incubator patch approval policy in conjunction with the nature of the
 projects it will attract.

 Due to the requirement for two core +2's in the Neutron incubator, moving
 group policy there is hardly going to do anything to reduce the load on the
 Neutron cores who are in a similar overloaded position as the Nova
 cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
 incubator receive even less core attention than the main repo simply
 because their location outside of openstack/neutron will be a good reason
 to treat them with a lower priority.

 If you combine that with the fact that the incubator is designed to house
 all of the proposed experimental features to Neutron, there will be a very
 high volume of patches constantly being proposed to add new features, make
 changes to features, and maybe even fix bugs in those features. This new
 demand for reviewers will not be met by the existing core reviewers because
 they will be busy with refactoring, fixing, and enhancing the core Neutron
 code.

 Even ignoring the review velocity issues, I see very little benefit to GBP
 starting inside of the Neutron incubator. It doesn't guarantee any
 packaging with Neutron and Neutron code cannot reference any incubator
 code. It's effectively a separate repo without the advantage of being able
 to commit code quickly.

 There is one potential downside to not immediately using the Neutron
 incubator. If the Neutron cores decide that all features must live in the
 incubator for at least 2 cycles regardless of quality or usage in
 deployments, starting outside in a StackForge project would delay the start
 of the timer until GBP makes it into the incubator. However, this can be
 considered once the incubator actually exists and starts accepting
 submissions.

 In summary, I think GBP should move to a StackForge project as soon as
 possible so development can progress. A transition to the Neutron incubator
 can be evaluated once it actually becomes something more than a wiki page.


 1.
 *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html*
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html

 --
 Kevin Benton


 On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami *dh

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Prasad Vellanki
Sumit
Thanks for initiating this and also good discussion today on the IRC.

My thoughts are that it is important to make this available to potential
users and customers as soon as possible so that we can get the necessary
feedback. Considering that the neutron cores and community are battling
nova parity and stability now, I would think it would be tough to get any
time for incubator or neutron feature branch any time soon.
I would think it would be better to move GBP into stackforge and then look
at incubator or neutron feature branch when available.

prasadv


On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
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)

 Thanks!

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

 ___
 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


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Mandeep Dhami
I agree. Also, as this does not preclude using the incubator when it is
ready, this is a good way to start iterating on implementation in parallel
with those issues being addressed by the community.

In my view, the issues raised around the incubator were significant enough
(around packaging, handling of updates needed for horizon/heat/celiometer,
handling of multiple feature branches, etc) that we we will probably need a
design session in paris before a consensus will emerge around a solution
for the incubator structure/usage. And if you are following the thread on
nova for 'Averting the Nova crisis ...', the final consensus might actually
BE to use separate stackforge project for plugins anyways, and in that case
we will have a head start ;-)

Regards,
Mandeep
-


On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:

 Sumit
 Thanks for initiating this and also good discussion today on the IRC.

 My thoughts are that it is important to make this available to potential
 users and customers as soon as possible so that we can get the necessary
 feedback. Considering that the neutron cores and community are battling
 nova parity and stability now, I would think it would be tough to get any
 time for incubator or neutron feature branch any time soon.
 I would think it would be better to move GBP into stackforge and then look
 at incubator or neutron feature branch when available.

 prasadv


 On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
 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)

 Thanks!

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Stephen Wong
I agree with Prasad here.

There remains lots of unknown about Neutron incubator and its workflow at
this point, and the idea of Neutron feature branch is at best in embryonic
stage. It seems like among the three options, the most well-defined one is
indeed through stackforge.

When and if the Neutron incubator and/or feature branch process and policy
are better defined, we as a community can assess whether it make sense for
GBP to apply for one of those programs. In the meantime, let's get this
feature in the hands of the early adopters and iterate on our
implementation and further enhancements accordingly.

- Stephen



On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:

 Sumit
 Thanks for initiating this and also good discussion today on the IRC.

 My thoughts are that it is important to make this available to potential
 users and customers as soon as possible so that we can get the necessary
 feedback. Considering that the neutron cores and community are battling
 nova parity and stability now, I would think it would be tough to get any
 time for incubator or neutron feature branch any time soon.
 I would think it would be better to move GBP into stackforge and then look
 at incubator or neutron feature branch when available.

 prasadv


 On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
 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)

 Thanks!

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Kevin Benton
Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
StackForge to make progress and re-evaluate when the incubator exists.


I also agree that starting out in StackForge as a separate repo is a better
first step. In addition to the uncertainty around packaging and other
processes brought up by Mandeep, I really doubt the Neutron incubator is
going to have the review velocity desired by the group policy contributors.
I believe this will be the case based on the Neutron incubator patch
approval policy in conjunction with the nature of the projects it will
attract.

Due to the requirement for two core +2's in the Neutron incubator, moving
group policy there is hardly going to do anything to reduce the load on the
Neutron cores who are in a similar overloaded position as the Nova
cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
incubator receive even less core attention than the main repo simply
because their location outside of openstack/neutron will be a good reason
to treat them with a lower priority.

If you combine that with the fact that the incubator is designed to house
all of the proposed experimental features to Neutron, there will be a very
high volume of patches constantly being proposed to add new features, make
changes to features, and maybe even fix bugs in those features. This new
demand for reviewers will not be met by the existing core reviewers because
they will be busy with refactoring, fixing, and enhancing the core Neutron
code.

Even ignoring the review velocity issues, I see very little benefit to GBP
starting inside of the Neutron incubator. It doesn't guarantee any
packaging with Neutron and Neutron code cannot reference any incubator
code. It's effectively a separate repo without the advantage of being able
to commit code quickly.

There is one potential downside to not immediately using the Neutron
incubator. If the Neutron cores decide that all features must live in the
incubator for at least 2 cycles regardless of quality or usage in
deployments, starting outside in a StackForge project would delay the start
of the timer until GBP makes it into the incubator. However, this can be
considered once the incubator actually exists and starts accepting
submissions.

In summary, I think GBP should move to a StackForge project as soon as
possible so development can progress. A transition to the Neutron incubator
can be evaluated once it actually becomes something more than a wiki page.


1.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html

--
Kevin Benton


On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami dh...@noironetworks.com
wrote:


 I agree. Also, as this does not preclude using the incubator when it is
 ready, this is a good way to start iterating on implementation in parallel
 with those issues being addressed by the community.

 In my view, the issues raised around the incubator were significant enough
 (around packaging, handling of updates needed for horizon/heat/celiometer,
 handling of multiple feature branches, etc) that we we will probably need a
 design session in paris before a consensus will emerge around a solution
 for the incubator structure/usage. And if you are following the thread on
 nova for 'Averting the Nova crisis ...', the final consensus might actually
 BE to use separate stackforge project for plugins anyways, and in that case
 we will have a head start ;-)

 Regards,
 Mandeep
 -


 On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
 prasad.vella...@oneconvergence.com wrote:

 Sumit
 Thanks for initiating this and also good discussion today on the IRC.

 My thoughts are that it is important to make this available to potential
 users and customers as soon as possible so that we can get the necessary
 feedback. Considering that the neutron cores and community are battling
 nova parity and stability now, I would think it would be tough to get any
 time for incubator or neutron feature branch any time soon.
 I would think it would be better to move GBP into stackforge and then
 look at incubator or neutron feature branch when available.

 prasadv


 On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
  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 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Mohammad Banikazemi
I can only see the use of a separate project for Group Policy as a tactical
and temporary solution. In my opinion, it does not make sense to have the
Group Policy as a separate project outside Neutron (unless the new project
is aiming to replace Neutron and I do not think anybody is suggesting
that). In this regard, Group Policy is not similar to Advanced Services
such as FW and LB.

So, using StackForge to get things moving again is fine but let us keep in
mind (and see if we can agree on) that we want to have the Group Policy
abstractions as part of OpenStack Networking (when/if it proves to be a
valuable extension to what we currently have). I do not want to see our
decision to make things moving quickly right now prevent us from achieving
that goal. That is why I think the other two approaches (from the little I
know about the incubator option, and even littler I know about the feature
branch option) may be better options in the long run.

If I understand it correctly some members of the community are actively
working on these options (that is, the incubator and the Neutron feature
branch options) . In order to make a better judgement as to how to proceed,
it would be very helpful if we get a bit more information on these two
options and their status here on this mailing list.

Mohammad





From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   09/05/2014 04:31 AM
Subject:Re: [openstack-dev] [neutron][policy] Group-based Policy next
steps



Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
StackForge to make progress and re-evaluate when the incubator exists.


I also agree that starting out in StackForge as a separate repo is a better
first step. In addition to the uncertainty around packaging and other
processes brought up by Mandeep, I really doubt the Neutron incubator is
going to have the review velocity desired by the group policy contributors.
I believe this will be the case based on the Neutron incubator patch
approval policy in conjunction with the nature of the projects it will
attract.

Due to the requirement for two core +2's in the Neutron incubator, moving
group policy there is hardly going to do anything to reduce the load on the
Neutron cores who are in a similar overloaded position as the Nova
cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
incubator receive even less core attention than the main repo simply
because their location outside of openstack/neutron will be a good reason
to treat them with a lower priority.

If you combine that with the fact that the incubator is designed to house
all of the proposed experimental features to Neutron, there will be a very
high volume of patches constantly being proposed to add new features, make
changes to features, and maybe even fix bugs in those features. This new
demand for reviewers will not be met by the existing core reviewers because
they will be busy with refactoring, fixing, and enhancing the core Neutron
code.

Even ignoring the review velocity issues, I see very little benefit to GBP
starting inside of the Neutron incubator. It doesn't guarantee any
packaging with Neutron and Neutron code cannot reference any incubator
code. It's effectively a separate repo without the advantage of being able
to commit code quickly.

There is one potential downside to not immediately using the Neutron
incubator. If the Neutron cores decide that all features must live in the
incubator for at least 2 cycles regardless of quality or usage in
deployments, starting outside in a StackForge project would delay the start
of the timer until GBP makes it into the incubator. However, this can be
considered once the incubator actually exists and starts accepting
submissions.

In summary, I think GBP should move to a StackForge project as soon as
possible so development can progress. A transition to the Neutron incubator
can be evaluated once it actually becomes something more than a wiki page.


1.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html

--
Kevin Benton


On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami dh...@noironetworks.com
wrote:

  I agree. Also, as this does not preclude using the incubator when it is
  ready, this is a good way to start iterating on implementation in
  parallel with those issues being addressed by the community.

  In my view, the issues raised around the incubator were significant
  enough (around packaging, handling of updates needed for
  horizon/heat/celiometer, handling of multiple feature branches, etc) that
  we we will probably need a design session in paris before a consensus
  will emerge around a solution for the incubator structure/usage. And if
  you are following the thread on nova for 'Averting the Nova crisis ...',
  the final consensus might actually BE to use separate stackforge project
  for plugins