Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Maru Newby
On Aug 8, 2014, at 10:56 AM, Kevin Benton blak...@gmail.com wrote:

 There is an enforcement component to the group policy that allows you to use 
 the current APIs and it's the reason that group policy is integrated into the 
 neutron project. If someone uses the current APIs, the group policy plugin 
 will make sure they don't violate any policy constraints before passing the 
 request into the regular core/service plugins.


The enforcement requirement might be easier to implement through code-based 
integration, but a separate service could provide the same guarantee against 
constraint violation by proxying v2 API calls for an endpoint to which access 
was restricted.

Apologies if I've missed discussion of this (it's a big thread), but won't 
enforcement by group policy on the v2 API have the potential to violate 
stability requirements?  If new errors related to enforcement can result from 
API calls, that would seem to be a change in behavior.  Do we have a precedent 
for allowing extensions or new services to modify core behavior in this way?


m. 

 
 
 On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando sorla...@nicira.com 
 wrote:
 It might be because of the wording used, but it seems to me that you're 
 making it sound like the group policy effort could have been completely 
 orthogonal to neutron as we know it now.
 
 What I understood is that the declarative abstraction offered by group policy 
 could do without any existing neutron entity leveraging native drivers, but 
 can actually be used also with existing neutron plugins through the mapping 
 driver - which will provide a sort of backward compatibility. And still in 
 that case I'm not sure one would be able to use traditional neutron API (or 
 legacy as it has been called), since I don't know if the mapping driver is 
 bidirectional.
 
 I know this probably stems from my ignorance on the subject - I had 
 unfortunately very little time to catch-up with this effort in the past 
 months.
 
 Salvatore
 
 
 On 8 August 2014 18:49, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hi Jay,
 
 You can choose. The whole purpose of this is about flexibility, if you want 
 to use GBP API 'only' with a specific driver you just can.
 Additionally, given the 'ML2 like' architecture, the reference mapping driver 
 can ideally run alongside by filling the core Neutron constructs without ever 
 'disturbing' your own driver (I'm not entirely sure about this but it seems 
 feasible).
 
 I hope this answers your question,
 Ivar.
 
 
 On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/08/2014 08:55 AM, Kevin Benton wrote:
 The existing constructs will not change.
 
 A followup question on the above...
 
 If GPB API is merged into Neutron, the next logical steps (from what I can 
 tell) will be to add drivers that handle policy-based payloads/requests.
 
 Some of these drivers, AFAICT, will *not* be deconstructing these policy 
 requests into the low-level port, network, and subnet 
 creation/attachment/detachment commands, but instead will be calling out 
 as-is to hardware that speaks the higher-level abstraction API [1], not the 
 lower-level port/subnet/network APIs. The low-level APIs would essentially be 
 consumed entirely within the policy-based driver, which would effectively 
 mean that the only way a system would be able to orchestrate networking in 
 systems using these drivers would be via the high-level policy API.
 
 Is that correct? Very sorry if I haven't explained clearly my question... 
 this is a tough question to frame eloquently :(
 
 Thanks,
 -jay
 
 [1] 
 http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
 
 On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:
 
 Wuhongning [mailto:wuhongn...@huawei.com
 mailto:wuhongn...@huawei.com] wrote:
 
  Does it make sense to move all advanced extension out of ML2, like
 security
  group, qos...? Then we can just talk about advanced service
 itself, without
  bothering basic neutron object (network/subnet/port)
 
 A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way of
 running AND iterating on GBP in conjunction with Neutron without being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.
 
 But, just so I'm not making a horrible mistake, can someone reassure me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?
 
 I'm under the impression that GBP is adding a higher level abstraction
 but that it's not ripping basic 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
The only issue with the separate service proxying API calls is that it
can't receive requests between the service and core plugins.

What kind of stability requirements were you concerned about? A response
change would be similar to having a custom policy.json file where things
that violate constraints would result in a 403.
On Aug 8, 2014 1:04 PM, Maru Newby ma...@redhat.com wrote:

 On Aug 8, 2014, at 10:56 AM, Kevin Benton blak...@gmail.com wrote:

  There is an enforcement component to the group policy that allows you to
 use the current APIs and it's the reason that group policy is integrated
 into the neutron project. If someone uses the current APIs, the group
 policy plugin will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


 The enforcement requirement might be easier to implement through
 code-based integration, but a separate service could provide the same
 guarantee against constraint violation by proxying v2 API calls for an
 endpoint to which access was restricted.

 Apologies if I've missed discussion of this (it's a big thread), but won't
 enforcement by group policy on the v2 API have the potential to violate
 stability requirements?  If new errors related to enforcement can result
 from API calls, that would seem to be a change in behavior.  Do we have a
 precedent for allowing extensions or new services to modify core behavior
 in this way?


 m.

 
 
  On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando sorla...@nicira.com
 wrote:
  It might be because of the wording used, but it seems to me that you're
 making it sound like the group policy effort could have been completely
 orthogonal to neutron as we know it now.
 
  What I understood is that the declarative abstraction offered by group
 policy could do without any existing neutron entity leveraging native
 drivers, but can actually be used also with existing neutron plugins
 through the mapping driver - which will provide a sort of backward
 compatibility. And still in that case I'm not sure one would be able to use
 traditional neutron API (or legacy as it has been called), since I
 don't know if the mapping driver is bidirectional.
 
  I know this probably stems from my ignorance on the subject - I had
 unfortunately very little time to catch-up with this effort in the past
 months.
 
  Salvatore
 
 
  On 8 August 2014 18:49, Ivar Lazzaro ivarlazz...@gmail.com wrote:
  Hi Jay,
 
  You can choose. The whole purpose of this is about flexibility, if you
 want to use GBP API 'only' with a specific driver you just can.
  Additionally, given the 'ML2 like' architecture, the reference mapping
 driver can ideally run alongside by filling the core Neutron constructs
 without ever 'disturbing' your own driver (I'm not entirely sure about this
 but it seems feasible).
 
  I hope this answers your question,
  Ivar.
 
 
  On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:
  On 08/08/2014 08:55 AM, Kevin Benton wrote:
  The existing constructs will not change.
 
  A followup question on the above...
 
  If GPB API is merged into Neutron, the next logical steps (from what I
 can tell) will be to add drivers that handle policy-based payloads/requests.
 
  Some of these drivers, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would
 effectively mean that the only way a system would be able to orchestrate
 networking in systems using these drivers would be via the high-level
 policy API.
 
  Is that correct? Very sorry if I haven't explained clearly my
 question... this is a tough question to frame eloquently :(
 
  Thanks,
  -jay
 
  [1]
 http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
 
  On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
  mailto:pc2...@att.com wrote:
 
  Wuhongning [mailto:wuhongn...@huawei.com
  mailto:wuhongn...@huawei.com] wrote:
 
   Does it make sense to move all advanced extension out of ML2, like
  security
   group, qos...? Then we can just talk about advanced service
  itself, without
   bothering basic neutron object (network/subnet/port)
 
  A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
  still
  think it's too late in the game to be shooting down all the work
  that the
  GBP team has put in unless there's a really clean and effective way
 of
  running AND iterating on GBP in conjunction with Neutron without
 being
  part of the Juno release. As far as I can tell they've worked really
  hard to follow the process and accommodate input. They 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Are there any parity features you are aware of that aren't receiving
adequate developer/reviewer time? I'm not aware of any parity features that
are in a place where throwing more engineers at them is going to speed
anything up. Maybe Mark McClain (Nova parity leader) can provide some
better insight here, but that is the impression I've gotten as an active
Neutron contributor observing the ongoing parity work.

Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing API
endpoints and I don't think it was ever the expectation that Nova would
switch to this during the Juno timeframe anyway. The new API will not be
used during normal operation and should not impact the existing API at all.


On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense. But,
  other than Mark's -2 blocking the initial patches from merging, we
  are on track to complete the planned work in Juno.
 
  -Bob
 
 
 
  As a member of nova-core, I find this whole discussion very startling.
  Putting aside the concerns over technical details and the pain of having
  in tree experimental APIs (such as nova v3 API), neutron still isn't the
  de-facto networking solution from nova's perspective and it won't be
  until neutron has feature and performance parity with nova-network. In
  fact due to the slow maturation of neutron, nova has moved nova-network
  from 'frozen' to open for development (with a few caveats).  So unless
  this new API directly solves some of the gaps in [0], I see no reason to
  push this into Juno. Juno hardly seems to be the appropriate time to
  introduce a new not-so-stable API; Juno is the time to address all the
  gaps [0] and hit feature and performance parity with nova-network.
 
 
  [0]
 
 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

 I would agree.

 There has been a pretty regular issue with Neutron team members working
 on new features instead of getting Neutron to feature parity with Nova
 network so we can retire the thing. This whole push for another API at
 this stage makes no sense to me.

 -Sean

 --
 Sean Dague
 http://dague.net

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




-- 
Kevin Benton

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton


On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

On 08/05/2014 01:23 PM, Gary Kotton wrote:
 Ok, thanks for the clarification. This means that it will not be done
 automagically as it is today ­ the tenant will need to create a Neutron
 port and then pass that through.

FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
like to get rid of automatic port creation, but can't do that in the
current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation? 


-- 
Russell Bryant

___
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] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton
Correct, this work is orthogonal to the parity work, which I understand is 
coming along very nicely. Do new features in Nova also require parity - 
https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
 (for example enables the MTU to be configured instead of via a configuration 
variable)
At the moment it seems like a moving target.

From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 9:12 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Are there any parity features you are aware of that aren't receiving adequate 
developer/reviewer time? I'm not aware of any parity features that are in a 
place where throwing more engineers at them is going to speed anything up. 
Maybe Mark McClain (Nova parity leader) can provide some better insight here, 
but that is the impression I've gotten as an active Neutron contributor 
observing the ongoing parity work.

Given that, pointing to the Nova parity work seems a bit like a red herring. 
This new API is being developed orthogonally to the existing API endpoints and 
I don't think it was ever the expectation that Nova would switch to this during 
the Juno timeframe anyway. The new API will not be used during normal operation 
and should not impact the existing API at all.


On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague 
s...@dague.netmailto:s...@dague.net wrote:
On 08/05/2014 07:28 PM, Joe Gordon wrote:



 On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.commailto:kuk...@noironetworks.com
 mailto:kuk...@noironetworks.commailto:kuk...@noironetworks.com wrote:

 On 8/4/14, 4:27 PM, Mark McClain wrote:
 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be
 should attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.
 The disconnect here is that the Neutron group-based policy sub-team
 that has been implementing this feature for Juno does not see this
 work as an experiment to gather data, but rather as an important
 innovative feature to put in the hands of early adopters in Juno and
 into widespread deployment with a stable API as early as Kilo.


 The group-based policy BP approved for Juno addresses the critical
 need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely
 with all existing core plugins. Additionally, we believe that this
 declarative approach is what is needed to properly integrate
 advanced services into Neutron, and will go a long way towards
 resolving the difficulties so far trying to integrate LBaaS, FWaaS,
 and VPNaaS APIs into the current Neutron model.

 Like any new service API in Neutron, the initial group policy API
 release will be subject to incompatible changes before being
 declared stable, and hence would be labeled experimental in
 Juno. This does not mean that it is an experiment where to fail
 fast is an acceptable outcome. The sub-team's goal is to stabilize
 the group policy API as quickly as possible,  making any needed
 changes based on early user and operator experience.

 The L and M cycles that Mark suggests below to revisit the status
 are a completely different time frame. By the L or M cycle, we
 should be working on a new V3 Neutron API that pulls these APIs
 together into a more cohesive core API. We will not be in a position
 to do this properly without the experience of using the proposed
 group policy extension with the V2 Neutron API in production.


 If we were failing miserably, or if serious technical issues were
 being identified with the patches, some delay might make sense. But,
 other than Mark's -2 blocking the initial patches from merging, we
 are on track to complete the planned work in Juno.

 -Bob



 As a member of nova-core, I find this whole discussion very startling.
 Putting aside the concerns over technical details and the pain of having
 in tree experimental APIs (such as nova v3 API), neutron still isn't the
 de-facto networking solution from nova's perspective and it won't be
 until neutron has feature and performance parity with nova-network. In
 fact due to the slow maturation of neutron, nova has moved nova-network
 from 'frozen' to open for development (with a few caveats).  So unless
 this new API directly solves some of the gaps in [0], I see no reason to
 push this into Juno. Juno hardly seems to be the appropriate time to
 introduce a new not-so-stable

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

 Can you elaborate on what you mean here? What are the issues with port
 creation?


Having nova-compute create ports for neutron is problematic if timeouts
occur between nova and neutron as you have to garbage collect neutron ports
in nova to cleanup (which was the cause of several bug in the cache handing
allowing ports to leak into the info_cache in nova).  Pushing this out to
the tenant is less orchestration nova has to do.



 --
 Russell Bryant
 
 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Masakazu Shinohara
Hi,

I'm Masakazu Shinohara of Cyberagent corporation in Japan.

I am a representative of our new cloud network project.
We have a lot of services such as on line games blogs or all kind of web
services.

Now we have been testing Openstack and Cisco ACI.
It is a really important thing that they can work correctly.

We have been observing, learning and following very closely the work going
on for Group Based Policy. Our production deployment relies on using it in
Juno. We strongly want to see it complete as proposed in Neutron.

Best regards

--
Masakazu Shinohara
CyberAgent,Inc
Ameba division Ameba Infra. Unit
Architect group
Zip code 150-0045
Shibuya First Place Bldg, 8-16 Shinsen-cho
Shibuya-ku Tokyo
Mobile +81 80-6863-2356
Extension 62478
shinohara_masak...@cyberagent.co.jp
---



From: Mark McClain mmccl...@yahoo-inc.com mailto:mmccl...@yahoo-inc.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, August 4, 2014 at 4:27 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron] Group Based Policy and the way forward

 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.


 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy
 (GBP) for many months.  I think the discussion has reached a point where
 we need to openly discuss a few issues before moving forward.  I
 recognize that this discussion could create frustration for those who
 have invested significant time and energy, but the reality is we need
 ensure we are making decisions that benefit all members of our community
 (users, operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.
   A good experiment should be designed to fail fast to enable further
 trials via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
   Releasing a new version of the proposed API every six months limits
 our ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental
 APIs.  The results have been very mixed as operators either shy away
 from testing/offering the API or embrace the API with the expectation
 that the community will provide full API support and migration.  In both
 cases, the experiment fails because we either could not get the data we
 need or are unable to make significant changes without accepting a
 non-trivial amount of technical debt via migrations or draft API support.

 Next Steps
 --
 Previously, the GPB subteam used a Github account to host the
 development, but the workflows and tooling do not align with OpenStack's
 development model. I’d like to see us create a group based policy
 project in StackForge.  StackForge will host the code and enable us to
 follow the same open review and QA processes we use in the main project
 while we are developing and testing the API. The infrastructure there
 will benefit us as we will have a separate review velocity and can
 frequently publish libraries to PyPI.  From a technical perspective, the
 13 new entities in GPB [1] do not require any changes to internal
 Neutron data structures.  The docs[2] also suggest that an external
 plugin or service would work to make it easier to speed development.

 End State
 -
 APIs require time to fully bake and right now it is too early to know
 the final outcome.  Using StackForge will allow the team to retain all
 of its options including: merging the code into Neutron, adopting the
 repository as sub-project of the Network Program, leaving the project in
 StackForge project or learning that users want something completely
 different.  I would expect that we'll revisit the status of the repo
 during the L or M cycles since the Kilo development cycle does not leave
 enough time to experiment and iterate.


 mark

 [1]
 http://git.openstack.org/cgit/openstack/neutron-specs/tree/
 specs/juno/group-based-policy-abstraction.rst#n370
 [2]
 https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWK
 WY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton gkot...@vmware.com wrote:
 Correct, this work is orthogonal to the parity work, which I understand is
 coming along very nicely.

Agree Gary and Kevin. I think the topic of Nova integration has
created confusion in people’s mind (at least the non-Neutron folks)
with regards to what is being proposed in the Group-based Policy (GBP)
feature. So to clarify - GBP is an optional extension, like many other
existing Neutron extensions. It is not meant to replace the Neutron
core API and/or the current Nova-Neutron interaction in Juno.

 Do new features in Nova also require parity -
 https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
 (for example enables the MTU to be configured instead of via a configuration
 variable)
 At the moment it seems like a moving target.

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 9:12 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 Are there any parity features you are aware of that aren't receiving
 adequate developer/reviewer time? I'm not aware of any parity features that
 are in a place where throwing more engineers at them is going to speed
 anything up. Maybe Mark McClain (Nova parity leader) can provide some better
 insight here, but that is the impression I've gotten as an active Neutron
 contributor observing the ongoing parity work.

 Given that, pointing to the Nova parity work seems a bit like a red herring.
 This new API is being developed orthogonally to the existing API endpoints
 and I don't think it was ever the expectation that Nova would switch to this
 during the Juno timeframe anyway. The new API will not be used during normal
 operation and should not impact the existing API at all.


 On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense. But,
  other than Mark's -2 blocking the initial patches from merging, we
  are on track to complete the planned work in Juno.
 
  -Bob
 
 
 
  As a member of nova-core, I find this whole discussion very startling.
  Putting aside the concerns over technical details and the pain of having
  in tree experimental APIs (such as nova v3 API), neutron still isn't the
  de-facto networking solution from nova's perspective and it won't be
  until neutron has feature

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton


From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:


On 8/5/14, 8:53 PM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:

On 08/05/2014 01:23 PM, Gary Kotton wrote:
 Ok, thanks for the clarification. This means that it will not be done
 automagically as it is today ­ the tenant will need to create a Neutron
 port and then pass that through.

FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
like to get rid of automatic port creation, but can't do that in the
current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation?


Having nova-compute create ports for neutron is problematic if timeouts occur 
between nova and neutron as you have to garbage collect neutron ports in nova 
to cleanup (which was the cause of several bug in the cache handing allowing 
ports to leak into the info_cache in nova).  Pushing this out to the tenant is 
less orchestration nova has to do.

[gary] my take on this is that we should allocate this via the n-api and not 
via the nova compute (which is far too late in the process. But that is another 
discussion :)



--
Russell Bryant

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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:



   From: Aaron Rosen aaronoro...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:09 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward


 On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

  Can you elaborate on what you mean here? What are the issues with port
 creation?


 Having nova-compute create ports for neutron is problematic if timeouts
 occur between nova and neutron as you have to garbage collect neutron ports
 in nova to cleanup (which was the cause of several bug in the cache handing
 allowing ports to leak into the info_cache in nova).  Pushing this out to
 the tenant is less orchestration nova has to do.

  [gary] my take on this is that we should allocate this via the n-api and
 not via the nova compute (which is far too late in the process. But that is
 another discussion :)


I agree, I had actually proposed this here:
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
 :),   though there are some issues we need to solve in neutron first --
allowing the mac_address on the port to be updated in neutron. This is
required for bare metal support as when the port is created we don't know
which physical mac will need to be mapped to the port.


   
 --
 Russell Bryant
 
 ___
 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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton


From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 11:11 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward




On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:


From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09 AM

To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:


On 8/5/14, 8:53 PM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:

On 08/05/2014 01:23 PM, Gary Kotton wrote:
 Ok, thanks for the clarification. This means that it will not be done
 automagically as it is today ­ the tenant will need to create a Neutron
 port and then pass that through.

FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
like to get rid of automatic port creation, but can't do that in the
current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation?


Having nova-compute create ports for neutron is problematic if timeouts occur 
between nova and neutron as you have to garbage collect neutron ports in nova 
to cleanup (which was the cause of several bug in the cache handing allowing 
ports to leak into the info_cache in nova).  Pushing this out to the tenant is 
less orchestration nova has to do.

[gary] my take on this is that we should allocate this via the n-api and not 
via the nova compute (which is far too late in the process. But that is another 
discussion :)

I agree, I had actually proposed this here: 
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-porthttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/nova-api-quantum-create-portk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=nxi%2BsVOGOwFKN8cKE9T4thh6hF%2Fbbz59EZEBQvd1lkE%3D%0As=50f7fe08f64d0d647ee97a8da6f91091e380cca72e84d06fa9c57c62dbb4e4ee
  :),   though there are some issues we need to solve in neutron first -- 
allowing the mac_address on the port to be updated in neutron. This is required 
for bare metal support as when the port is created we don't know which physical 
mac will need to be mapped to the port.

[gary] agreed


--
Russell Bryant

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


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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] Group Based Policy and the way forward

2014-08-06 Thread Christopher Yeoh
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:



   From: Aaron Rosen aaronoro...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:09 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward


 On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a
 Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

  Can you elaborate on what you mean here? What are the issues with port
 creation?


 Having nova-compute create ports for neutron is problematic if timeouts
 occur between nova and neutron as you have to garbage collect neutron ports
 in nova to cleanup (which was the cause of several bug in the cache handing
 allowing ports to leak into the info_cache in nova).  Pushing this out to
 the tenant is less orchestration nova has to do.

  [gary] my take on this is that we should allocate this via the n-api
 and not via the nova compute (which is far too late in the process. But
 that is another discussion :)


 I agree, I had actually proposed this here:
 https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
  :),   though there are some issues we need to solve in neutron first --
 allowing the mac_address on the port to be updated in neutron. This is
 required for bare metal support as when the port is created we don't know
 which physical mac will need to be mapped to the port.




I think that in the long term (when we can do an API rev) we should just be
getting rid of the automatic port creation completely with the updated Nova
API. I don't see why the Nova API needs to do proxying work to neutron to
create the port when the client can do it directly with neutron (perhaps
via some convenience client code if desired). It removes the complexity of
the garbage collection on failure issues in Nova that we currently have.

Chris



   
 --
 Russell Bryant
 
 ___
 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



 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Kyle Mestery
On Wed, Aug 6, 2014 at 3:11 AM, Aaron Rosen aaronoro...@gmail.com wrote:



 On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:



 From: Aaron Rosen aaronoro...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:09 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward


 On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a
  Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

 Can you elaborate on what you mean here? What are the issues with port
 creation?


 Having nova-compute create ports for neutron is problematic if timeouts
 occur between nova and neutron as you have to garbage collect neutron ports
 in nova to cleanup (which was the cause of several bug in the cache handing
 allowing ports to leak into the info_cache in nova).  Pushing this out to
 the tenant is less orchestration nova has to do.

 [gary] my take on this is that we should allocate this via the n-api and
 not via the nova compute (which is far too late in the process. But that is
 another discussion :)


 I agree, I had actually proposed this here:
 https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
 :),   though there are some issues we need to solve in neutron first --
 allowing the mac_address on the port to be updated in neutron. This is
 required for bare metal support as when the port is created we don't know
 which physical mac will need to be mapped to the port.

Looks like someone has proposed a patch which does just that, please
have a look below:

https://review.openstack.org/#/c/112129/


 
 --
 Russell Bryant
 
 ___
 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



 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Russell Bryant
On 08/05/2014 05:24 PM, Sumit Naiksatam wrote:
 On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/05/2014 04:26 PM, Stephen Wong wrote:

 Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
 integration, and the preliminary idea, as Bob alluded to, is to add
 endpoint as an option in place of Neutron port. But if we can make
 Nova EPG-aware, it would be great.


 Is anyone listening to what I'm saying? The term endpoint is obtuse and
 completely disregards the existing denotation of the word endpoint in use
 in OpenStack today.

 
 Yes, listening, absolutely. I acknowledged your point in this thread
 as well as on the review. Your suggestion on the thread seemed to be
 to document this better and clarify. Is that sufficient for moving
 forward, or are you thinking something else?

I agree with Jay's concern here.  I think using the term endpoint at
all is problematic and should be renamed to something else.  As Jay has
stated, endpoint is already a well defined and completely different
concept in OpenStack.  What's being created here should be called
something else.

-- 
Russell Bryant

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Russell Bryant
On 08/05/2014 06:13 PM, Kevin Benton wrote:
 That makes sense. It's not quite a fair analogy though to compare to
 reintroducing projects or tenants because Keystone endpoints aren't
 'user-facing' so to speak. i.e. a regular user (application deployer,
 instance operator, etc) should never have to see or understand the
 purpose of a Keystone endpoint.

An end user that is consuming any OpenStack API absolutely must
understand endpoints in the service catalog.  The entire purpose of the
catalog is so that an application only needs to know the API endpoint to
keystone and is then able to discover where the rest of the APIs are
located.  They are very much user facing, IMO.

-- 
Russell Bryant

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Carlino, Chuck (OpenStack TripleO, Neutron)
On Aug 6, 2014, at 1:11 AM, Aaron Rosen 
aaronoro...@gmail.commailto:aaronoro...@gmail.com wrote:

I agree, I had actually proposed this here: 
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port  :),   
though there are some issues we need to solve in neutron first -- allowing the 
mac_address on the port to be updated in neutron. This is required for bare 
metal support as when the port is created we don't know which physical mac will 
need to be mapped to the port.


FYI, this is work in progress (see 
https://bugs.launchpad.net/neutron/+bug/1341268 and 
https://review.openstack.org/#/c/112129/).

Chuck Carlino

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Joe Gordon
On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton blak...@gmail.com wrote:

 Are there any parity features you are aware of that aren't receiving
 adequate developer/reviewer time? I'm not aware of any parity features that
 are in a place where throwing more engineers at them is going to speed
 anything up. Maybe Mark McClain (Nova parity leader) can provide some
 better insight here, but that is the impression I've gotten as an active
 Neutron contributor observing the ongoing parity work.


I cannot speak for which parts of nova-parity are short staffed, if any,
but from an outsiders perspective I don't think neutron will hit full
parity in Juno. And I would be very surprised to hear that more developers
working on parity won't help. For example we are already in Juno-3 and the
following work is yet to be completed (as per the neutron gap wiki):

* Make check-tempest-dsvm-neutron-full stable enough to vote
* Grenade testing
* DVR (Neutron replacement for Nova multi-host)
* Document Open Source Options
* Real world (not in gate) performance, stability and scalability testing
(performance parity with nova-networking).




 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing API
 endpoints and I don't think it was ever the expectation that Nova would
 switch to this during the Juno timeframe anyway. The new API will not be
 used during normal operation and should not impact the existing API at all.






 On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense. But,
  other than Mark's -2 blocking the initial patches from merging, we
  are on track to complete the planned work in Juno.
 
  -Bob
 
 
 
  As a member of nova-core, I find this whole discussion very startling.
  Putting aside the concerns over technical details and the pain of having
  in tree experimental APIs (such as nova v3 API), neutron still isn't the
  de-facto networking solution from nova's perspective and it won't be
  until neutron has feature and performance parity with nova-network. In
  fact due to the slow maturation of neutron, nova has moved nova-network
  from 'frozen' to open for development (with a few caveats).  So unless
  this new API directly solves some of the gaps in [0], I see no reason to
  push this into Juno. Juno hardly seems to be the appropriate time to
  introduce a new not-so-stable API; Juno is the time to address all 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes

On 08/06/2014 02:12 AM, Kevin Benton wrote:

Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints


You see how you used the term endpoints there? :P

-jay

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova
Parity for the Juno release? Because then I fail to see why this and Mark's
proposal are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP
approval time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in
Neutron (which basically is a workflow change), we should discuss all of it
for the next release without blocking patches which went through the whole
approval process and are ready to be merged after community effort (BP
process, Weakly meetings, POC, reviews). Just like has been done in other
similar cases (eg. 3rd Party CI). This of course is IMHO.

Ivar.
On Aug 6, 2014 4:55 PM, Joe Gordon joe.gord...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton blak...@gmail.com wrote:

 Are there any parity features you are aware of that aren't receiving
 adequate developer/reviewer time? I'm not aware of any parity features that
 are in a place where throwing more engineers at them is going to speed
 anything up. Maybe Mark McClain (Nova parity leader) can provide some
 better insight here, but that is the impression I've gotten as an active
 Neutron contributor observing the ongoing parity work.


 I cannot speak for which parts of nova-parity are short staffed, if any,
 but from an outsiders perspective I don't think neutron will hit full
 parity in Juno. And I would be very surprised to hear that more developers
 working on parity won't help. For example we are already in Juno-3 and the
 following work is yet to be completed (as per the neutron gap wiki):

 * Make check-tempest-dsvm-neutron-full stable enough to vote
 * Grenade testing
 * DVR (Neutron replacement for Nova multi-host)
 * Document Open Source Options
 * Real world (not in gate) performance, stability and scalability testing
 (performance parity with nova-networking).




 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing API
 endpoints and I don't think it was ever the expectation that Nova would
 switch to this during the Juno timeframe anyway. The new API will not be
 used during normal operation and should not impact the existing API at all.






 On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno
 and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a
 position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense.
 But,
  other than 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
It sounds to me like you are describing how a developer uses Keystone, not
a user. My reference to 'application deployer' was to someone trying to run
something like a mail server on an openstack cloud.
On Aug 6, 2014 7:07 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 06:13 PM, Kevin Benton wrote:
  That makes sense. It's not quite a fair analogy though to compare to
  reintroducing projects or tenants because Keystone endpoints aren't
  'user-facing' so to speak. i.e. a regular user (application deployer,
  instance operator, etc) should never have to see or understand the
  purpose of a Keystone endpoint.

 An end user that is consuming any OpenStack API absolutely must
 understand endpoints in the service catalog.  The entire purpose of the
 catalog is so that an application only needs to know the API endpoint to
 keystone and is then able to discover where the rest of the APIs are
 located.  They are very much user facing, IMO.

 --
 Russell Bryant

 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
In the weekly neutron meetings it hasn't been mentioned that any of these
items are at risk due to developer shortage. That's why I wanted Mark
McClain to reply here because he has been leading the parity effort.
On Aug 6, 2014 8:56 AM, Joe Gordon joe.gord...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton blak...@gmail.com wrote:

 Are there any parity features you are aware of that aren't receiving
 adequate developer/reviewer time? I'm not aware of any parity features that
 are in a place where throwing more engineers at them is going to speed
 anything up. Maybe Mark McClain (Nova parity leader) can provide some
 better insight here, but that is the impression I've gotten as an active
 Neutron contributor observing the ongoing parity work.


 I cannot speak for which parts of nova-parity are short staffed, if any,
 but from an outsiders perspective I don't think neutron will hit full
 parity in Juno. And I would be very surprised to hear that more developers
 working on parity won't help. For example we are already in Juno-3 and the
 following work is yet to be completed (as per the neutron gap wiki):

 * Make check-tempest-dsvm-neutron-full stable enough to vote
 * Grenade testing
 * DVR (Neutron replacement for Nova multi-host)
 * Document Open Source Options
 * Real world (not in gate) performance, stability and scalability testing
 (performance parity with nova-networking).




 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing API
 endpoints and I don't think it was ever the expectation that Nova would
 switch to this during the Juno timeframe anyway. The new API will not be
 used during normal operation and should not impact the existing API at all.






 On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno
 and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a
 position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense.
 But,
  other than Mark's -2 blocking the initial patches from merging, we
  are on track to complete the planned work in Juno.
 
  -Bob
 
 
 
  As a member of nova-core, I find this whole discussion very startling.
  Putting aside the concerns over technical details and the pain of
 having
  in tree experimental APIs (such as nova v3 API), neutron still isn't
 the
  de-facto networking solution from nova's perspective and it won't be
  until neutron has feature and performance parity with nova-network. In
  fact due to the slow maturation of neutron, nova has moved 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
As a cloud admin one needs to make sure the endpoints in keystone
publicurl, internalurl and adminurl all map to the right places in the
infrastructure. As a cloud user (for example when using the HP/RAX public
cloud that has multiple regions/endpoints) a user needs to be aware of
which region maps to which endpoint.


On Wed, Aug 6, 2014 at 9:56 AM, Kevin Benton blak...@gmail.com wrote:

 It sounds to me like you are describing how a developer uses Keystone, not
 a user. My reference to 'application deployer' was to someone trying to run
 something like a mail server on an openstack cloud.
 On Aug 6, 2014 7:07 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 06:13 PM, Kevin Benton wrote:
  That makes sense. It's not quite a fair analogy though to compare to
  reintroducing projects or tenants because Keystone endpoints aren't
  'user-facing' so to speak. i.e. a regular user (application deployer,
  instance operator, etc) should never have to see or understand the
  purpose of a Keystone endpoint.

 An end user that is consuming any OpenStack API absolutely must
 understand endpoints in the service catalog.  The entire purpose of the
 catalog is so that an application only needs to know the API endpoint to
 keystone and is then able to discover where the rest of the APIs are
 located.  They are very much user facing, IMO.

 --
 Russell Bryant

 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Ronak Shah
We have diverged our attention towards nova-network- neutron parity on
this thread unnecessarily.

Can we discuss and collectively decide on what is the way forward for GBP
in Juno release?

Efforts have been made by the subteam starting from throwing PoC at last
summit to spec approval to code review.

There are usefulness to this feature and I think everyone is on the same
page there.

Let us not discourage the effort by bringing in existing neutron issue in
play.
Yes, we has a neutorn community needs to fix that with highest priority.
But this is orthogonal effort.
If endpoint is not a likeable preferred name than lets propose more
meaningful alternative.
Let us try to find a middle ground on how this feature can be made
generally available.

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
What I was referring to was also not Keystone's definition of an endpoint.
It's almost as if the term has many uses and was not invented for Keystone.
:-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template'
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Joe Gordon
On Aug 6, 2014 10:21 AM, Ronak Shah ronak.malav.s...@gmail.com wrote:

 We have diverged our attention towards nova-network- neutron parity on
this thread unnecessarily.

 Can we discuss and collectively decide on what is the way forward for GBP
in Juno release?

 Efforts have been made by the subteam starting from throwing PoC at last
summit to spec approval to code review.

 There are usefulness to this feature and I think everyone is on the same
page there.

 Let us not discourage the effort by bringing in existing neutron issue in
play.

 Yes, we has a neutorn community needs to fix that with highest priority.
 But this is orthogonal effort.

The efforts may be orthogonal, but the review team and bandwidth of said
team is one and the same. Making nova-network the highest priority means
pushing other blueprints back as needed.  And since there is still so much
uncertainty around GPB this late in the cycle, IMHO it's a good candidate
for getting deferred.

 If endpoint is not a likeable preferred name than lets propose more
meaningful alternative.
 Let us try to find a middle ground on how this feature can be made
generally available.

 Thanks,
 Ronak

 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Sridar Kandaswamy (skandasw)
Hi All:

+1 Ivar. Yes the timing of the alternate proposal does make the notion of spec 
reviews seem like a process tick mark with no seeming benefit. It is indeed 
unfair to the folks who have put in a lot of effort with an approved spec to 
have a workflow change pulled on them so late in the cycle.

Thanks

Sridar

From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 12:01 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova Parity 
for the Juno release? Because then I fail to see why this and Mark's proposal 
are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP approval 
time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in 
Neutron (which basically is a workflow change), we should discuss all of it for 
the next release without blocking patches which went through the whole approval 
process and are ready to be merged after community effort (BP process, Weakly 
meetings, POC, reviews). Just like has been done in other similar cases (eg. 
3rd Party CI). This of course is IMHO.

Ivar.

On Aug 6, 2014 4:55 PM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:



On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:
Are there any parity features you are aware of that aren't receiving adequate 
developer/reviewer time? I'm not aware of any parity features that are in a 
place where throwing more engineers at them is going to speed anything up. 
Maybe Mark McClain (Nova parity leader) can provide some better insight here, 
but that is the impression I've gotten as an active Neutron contributor 
observing the ongoing parity work.

I cannot speak for which parts of nova-parity are short staffed, if any, but 
from an outsiders perspective I don't think neutron will hit full parity in 
Juno. And I would be very surprised to hear that more developers working on 
parity won't help. For example we are already in Juno-3 and the following work 
is yet to be completed (as per the neutron gap wiki):

* Make check-tempest-dsvm-neutron-full stable enough to vote
* Grenade testing
* DVR (Neutron replacement for Nova multi-host)
* Document Open Source Options
* Real world (not in gate) performance, stability and scalability testing 
(performance parity with nova-networking).



Given that, pointing to the Nova parity work seems a bit like a red herring. 
This new API is being developed orthogonally to the existing API endpoints and 
I don't think it was ever the expectation that Nova would switch to this during 
the Juno timeframe anyway. The new API will not be used during normal operation 
and should not impact the existing API at all.



On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague 
s...@dague.netmailto:s...@dague.net wrote:
On 08/05/2014 07:28 PM, Joe Gordon wrote:



 On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.commailto:kuk...@noironetworks.com
 mailto:kuk...@noironetworks.commailto:kuk...@noironetworks.com wrote:

 On 8/4/14, 4:27 PM, Mark McClain wrote:
 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be
 should attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.
 The disconnect here is that the Neutron group-based policy sub-team
 that has been implementing this feature for Juno does not see this
 work as an experiment to gather data, but rather as an important
 innovative feature to put in the hands of early adopters in Juno and
 into widespread deployment with a stable API as early as Kilo.


 The group-based policy BP approved for Juno addresses the critical
 need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely
 with all existing core plugins. Additionally, we believe that this
 declarative approach is what is needed to properly integrate
 advanced services into Neutron, and will go a long way towards
 resolving the difficulties so far trying to integrate LBaaS, FWaaS,
 and VPNaaS APIs into the current Neutron model.

 Like any new service API in Neutron, the initial group policy API
 release will be subject to incompatible changes before being
 declared stable, and hence would be labeled experimental in
 Juno. This does not mean that it is an experiment where to fail

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
For instance: endpoints should be enforcement point

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:22 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?

On Aug 6, 2014 9:24 AM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Which kind of uncertainty are you referring to?

Given that the blueprint was approved long ago, and the code has been ready
and under review following those specs... I think GBP is probably the patch
with the least effort to be merged right now.

Ivar.


On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon joe.gord...@gmail.com wrote:


 On Aug 6, 2014 10:21 AM, Ronak Shah ronak.malav.s...@gmail.com wrote:
 
  We have diverged our attention towards nova-network- neutron parity on
 this thread unnecessarily.
 
  Can we discuss and collectively decide on what is the way forward for
 GBP in Juno release?
 
  Efforts have been made by the subteam starting from throwing PoC at last
 summit to spec approval to code review.
 
  There are usefulness to this feature and I think everyone is on the same
 page there.
 
  Let us not discourage the effort by bringing in existing neutron issue
 in play.

  Yes, we has a neutorn community needs to fix that with highest priority.
  But this is orthogonal effort.

 The efforts may be orthogonal, but the review team and bandwidth of said
 team is one and the same. Making nova-network the highest priority means
 pushing other blueprints back as needed.  And since there is still so much
 uncertainty around GPB this late in the cycle, IMHO it's a good candidate
 for getting deferred.

  If endpoint is not a likeable preferred name than lets propose more
 meaningful alternative.
  Let us try to find a middle ground on how this feature can be made
 generally available.
 
  Thanks,
  Ronak
 
  ___
  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] Group Based Policy and the way forward

2014-08-06 Thread Salvatore Orlando
As Ronak said, this thread is starting to move in a lot of different
directions, ranging from correctness of the blueprint approval process to
nova/neutron integration, which are rather off topic.

In particular it seems things are being skewed towards a discussion around
nova parity, whereas actually some people have just chimed in with their
honest opinion that with all the stuff still needed to finally be able to
make neutron THE openstack networking solution, the effort towards adding
a new tenant facing API appears to have a lesser priority.

I just want to reassure everybody that the majority of the core team and a
large part of the community have actually made this their first priority.
For what is worth, some of them have even delayed plugin/driver specific
development to this aim.

So I would invite to go back to the original subject of the discussion,
that is to say decide as a community what would the best way forward for
this effort.
I see so far the following options:
- merge the outstanding patches, assuming there are no further technical
concerns, and include GBP in Juno.
- consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
- delay to the next release
- move the development of the service plugin to stackforge as suggested to
this thread.

More options are obviously welcome!

Regards,
Salvatore


On 6 August 2014 19:40, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 Which kind of uncertainty are you referring to?

 Given that the blueprint was approved long ago, and the code has been
 ready and under review following those specs... I think GBP is probably the
 patch with the least effort to be merged right now.

 Ivar.


 On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon joe.gord...@gmail.com wrote:


 On Aug 6, 2014 10:21 AM, Ronak Shah ronak.malav.s...@gmail.com wrote:
 
  We have diverged our attention towards nova-network- neutron parity on
 this thread unnecessarily.
 
  Can we discuss and collectively decide on what is the way forward for
 GBP in Juno release?
 
  Efforts have been made by the subteam starting from throwing PoC at
 last summit to spec approval to code review.
 
  There are usefulness to this feature and I think everyone is on the
 same page there.
 
  Let us not discourage the effort by bringing in existing neutron issue
 in play.

  Yes, we has a neutorn community needs to fix that with highest
 priority.
  But this is orthogonal effort.

 The efforts may be orthogonal, but the review team and bandwidth of said
 team is one and the same. Making nova-network the highest priority means
 pushing other blueprints back as needed.  And since there is still so much
 uncertainty around GPB this late in the cycle, IMHO it's a good candidate
 for getting deferred.

  If endpoint is not a likeable preferred name than lets propose more
 meaningful alternative.
  Let us try to find a middle ground on how this feature can be made
 generally available.
 
  Thanks,
  Ronak
 
  ___
  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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes

On 08/06/2014 01:22 PM, Kevin Benton wrote:

What I was referring to was also not Keystone's definition of an
endpoint. It's almost as if the term has many uses and was not invented
for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word
'template' since this was clearly already in use by Horizon?


Not sure. But I do know that conversations around resource names in REST 
API endpoints (yes, that is how the term has been used in OpenStack) 
have been numerous. Just search for various conversations around project 
or tenant, or any of the Tuskar API modeling conversations. These kinds 
of discussions do come up often, and for good reason... these are the 
public APIs of OpenStack and are our first impression to the user, so 
to speak. It's a lot easier to try and get things right first than go 
through endless deprecation and backwards compatibility discussions. :)


Best,
-jay

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com wrote:
 This is the consequence of a proposal that is not following the standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you can see
 my comments were totally ignored:
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestion…

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an endpoint.
 It's almost as if the term has many uses and was not invented for Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word 'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Salvatore,

Can you expand on point 2? Not sure what means in this case to 'treat it
accordingly'.

Thanks,
Ivar.


On Wed, Aug 6, 2014 at 7:44 PM, Salvatore Orlando sorla...@nicira.com
wrote:

 As Ronak said, this thread is starting to move in a lot of different
 directions, ranging from correctness of the blueprint approval process to
 nova/neutron integration, which are rather off topic.

 In particular it seems things are being skewed towards a discussion around
 nova parity, whereas actually some people have just chimed in with their
 honest opinion that with all the stuff still needed to finally be able to
 make neutron THE openstack networking solution, the effort towards adding
 a new tenant facing API appears to have a lesser priority.

 I just want to reassure everybody that the majority of the core team and a
 large part of the community have actually made this their first priority.
 For what is worth, some of them have even delayed plugin/driver specific
 development to this aim.

 So I would invite to go back to the original subject of the discussion,
 that is to say decide as a community what would the best way forward for
 this effort.
 I see so far the following options:
 - merge the outstanding patches, assuming there are no further technical
 concerns, and include GBP in Juno.
 - consider GBP an 'experimental' V3 tenant API (this was mentioned
 somewhere in this thread) and treat it accordingly
 - delay to the next release
 - move the development of the service plugin to stackforge as suggested to
 this thread.

 More options are obviously welcome!

 Regards,
 Salvatore


 On 6 August 2014 19:40, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 Which kind of uncertainty are you referring to?

 Given that the blueprint was approved long ago, and the code has been
 ready and under review following those specs... I think GBP is probably the
 patch with the least effort to be merged right now.

 Ivar.


 On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon joe.gord...@gmail.com wrote:


 On Aug 6, 2014 10:21 AM, Ronak Shah ronak.malav.s...@gmail.com
 wrote:
 
  We have diverged our attention towards nova-network- neutron parity
 on this thread unnecessarily.
 
  Can we discuss and collectively decide on what is the way forward for
 GBP in Juno release?
 
  Efforts have been made by the subteam starting from throwing PoC at
 last summit to spec approval to code review.
 
  There are usefulness to this feature and I think everyone is on the
 same page there.
 
  Let us not discourage the effort by bringing in existing neutron issue
 in play.

  Yes, we has a neutorn community needs to fix that with highest
 priority.
  But this is orthogonal effort.

 The efforts may be orthogonal, but the review team and bandwidth of said
 team is one and the same. Making nova-network the highest priority means
 pushing other blueprints back as needed.  And since there is still so much
 uncertainty around GPB this late in the cycle, IMHO it's a good candidate
 for getting deferred.

  If endpoint is not a likeable preferred name than lets propose more
 meaningful alternative.
  Let us try to find a middle ground on how this feature can be made
 generally available.
 
  Thanks,
  Ronak
 
  ___
  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



 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.

Edgar

On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:
 
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an
endpoint.
 It's almost as if the term has many uses and was not invented for
Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word
'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

 ___
 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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com wrote:
 That is the beauty of the open source projects, there is always a smartest
 reviewer catching out the facts that you don¹t.

 Edgar

 On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:

https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an
endpoint.
 It's almost as if the term has many uses and was not invented for
Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word
'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

 ___
 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


 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Yapeng Wu
Hi, Salvatore,

Thanks listing out the options.

Can you elaborate more on your 2nd option? Do you mean merge the patches and 
mark the API as ‘experimental’?

Yapeng


From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, August 06, 2014 1:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

As Ronak said, this thread is starting to move in a lot of different 
directions, ranging from correctness of the blueprint approval process to 
nova/neutron integration, which are rather off topic.

In particular it seems things are being skewed towards a discussion around nova 
parity, whereas actually some people have just chimed in with their honest 
opinion that with all the stuff still needed to finally be able to make neutron 
THE openstack networking solution, the effort towards adding a new tenant 
facing API appears to have a lesser priority.

I just want to reassure everybody that the majority of the core team and a 
large part of the community have actually made this their first priority. For 
what is worth, some of them have even delayed plugin/driver specific 
development to this aim.

So I would invite to go back to the original subject of the discussion, that is 
to say decide as a community what would the best way forward for this effort.
I see so far the following options:
- merge the outstanding patches, assuming there are no further technical 
concerns, and include GBP in Juno.
- consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in 
this thread) and treat it accordingly
- delay to the next release
- move the development of the service plugin to stackforge as suggested to this 
thread.

More options are obviously welcome!

Regards,
Salvatore

On 6 August 2014 19:40, Ivar Lazzaro 
ivarlazz...@gmail.commailto:ivarlazz...@gmail.com wrote:
Which kind of uncertainty are you referring to?

Given that the blueprint was approved long ago, and the code has been ready and 
under review following those specs... I think GBP is probably the patch with 
the least effort to be merged right now.

Ivar.

On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:

On Aug 6, 2014 10:21 AM, Ronak Shah 
ronak.malav.s...@gmail.commailto:ronak.malav.s...@gmail.com wrote:

 We have diverged our attention towards nova-network- neutron parity on this 
 thread unnecessarily.

 Can we discuss and collectively decide on what is the way forward for GBP in 
 Juno release?

 Efforts have been made by the subteam starting from throwing PoC at last 
 summit to spec approval to code review.

 There are usefulness to this feature and I think everyone is on the same page 
 there.

 Let us not discourage the effort by bringing in existing neutron issue in 
 play.

 Yes, we has a neutorn community needs to fix that with highest priority.
 But this is orthogonal effort.

The efforts may be orthogonal, but the review team and bandwidth of said team 
is one and the same. Making nova-network the highest priority means pushing 
other blueprints back as needed.  And since there is still so much uncertainty 
around GPB this late in the cycle, IMHO it's a good candidate for getting 
deferred.
 If endpoint is not a likeable preferred name than lets propose more 
 meaningful alternative.
 Let us try to find a middle ground on how this feature can be made generally 
 available.

 Thanks,
 Ronak

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


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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] Group Based Policy and the way forward

2014-08-06 Thread Henry Fourie
+1

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Wednesday, August 06, 2014 10:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
For instance: endpoints should be enforcement point

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:22 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com
wrote:
 That is the beauty of the open source projects, there is always a
smartest
 reviewer catching out the facts that you don¹t.

 Edgar

 On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:

https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
Ir
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an
endpoint.
 It's almost as if the term has many uses and was not invented for
Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word
'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the
existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

 ___
 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


 ___
 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] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still
thought it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana edgar.mag...@workday.com
wrote:

 Basically, I am admitting that I did not catch in my review the part of
 the endpoint term that Jay was pointing out.

 Edgar

 On 8/6/14, 11:32 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

 Not sure what you are talking about? You claim now that you had
 suggestion which was not considered, yet you +2'ed a patch, by stating
 that All looks good to me!.
 
 On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com
 wrote:
  That is the beauty of the open source projects, there is always a
 smartest
  reviewer catching out the facts that you don¹t.
 
  Edgar
 
  On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:
 
 Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
 
 
 Edgar Magana
 Jul 2 8:42 AM
 
 Patch Set 13: Code-Review+2
 
 All looks good to me! I am not approving yet because Nachi was also
 reviewing this code and I would like to see his opinion as well.
 
 
 That would suggest that you were happy with what was in it. I don't
 see anything in the review comments that suggests otherwise.
 
 [1]  https://review.openstack.org/#/c/95900/
 
 On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com
 
 wrote:
  This is the consequence of a proposal that is not following the
 standardized
  terminology (IETF - RFC) for any Policy-based System:
  http://tools.ietf.org/html/rfc3198
 
  Well, I did bring  this point during the Hong Kong Summit but as you
 can see
  my comments were totally ignored:
 
 
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
 Ir
 upCD9E/edit
 
  I clearly saw this kind of issues coming. Let me quote myself what I
  suggested: For instance: endpoints should be enforcement point
 
  I do not understand why GBP did not include this suggestionŠ
 
  Edgar
 
  From: Kevin Benton blak...@gmail.com
  Reply-To: OpenStack Development Mailing List (not for usage
 questions)
  openstack-dev@lists.openstack.org
  Date: Wednesday, August 6, 2014 at 10:22 AM
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
 
  Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
  forward
 
  What I was referring to was also not Keystone's definition of an
 endpoint.
  It's almost as if the term has many uses and was not invented for
 Keystone.
  :-)
 
  http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
 
  Did a similar discussion occur when Heat wanted to use the word
 'template'
  since this was clearly already in use by Horizon?
 
  On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/06/2014 02:12 AM, Kevin Benton wrote:
 
  Given that, pointing to the Nova parity work seems a bit like a red
  herring. This new API is being developed orthogonally to the
 existing
  API endpoints
 
 
  You see how you used the term endpoints there? :P
 
  -jay
 
  ___
  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
 
 
  ___
  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

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 1:41 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, Sumit Naiksatam 
sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote:

Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com
wrote:
 That is the beauty of the open source projects, there is always a
smartest
 reviewer catching out the facts that you don¹t.

 Edgar

 On 8/6/14, 10:55 AM, Sumit Naiksatam 
 sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:

https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
Ir
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an
endpoint.
 It's almost as if the term has many uses and was not invented for
Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word
'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes 
 jaypi...@gmail.commailto:jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the
existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

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


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


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


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

___
OpenStack-dev mailing list
OpenStack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of
concerns was the BP approval. The fact that it has been approved after many
proposals and reviews means that a community effort wanted the GBP to be
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your
disagreement! I'm just saying that it should be expressed differently (a BP
to propose your model in K?). Otherwise, the whole BP process becomes just
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.
 On Aug 6, 2014 11:00 PM, Edgar Magana edgar.mag...@workday.com wrote:

  Ivar,

  Of course and this is why we are having this conversation, in order to
 merge our different opinions.

  Edgar

   From: Ivar Lazzaro ivarlazz...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 1:41 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

   Hi Edgar,

  Actually, I think that other reviewers saw that name clash, and still
 thought it was ok to use the same terminology in such a different context.
 BP reviews are a community effort right? So of course someones' idea may
 be different from yours.

  Regards,
 Ivar.


 On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana edgar.mag...@workday.com
 wrote:

 Basically, I am admitting that I did not catch in my review the part of
 the endpoint term that Jay was pointing out.

 Edgar

 On 8/6/14, 11:32 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

 Not sure what you are talking about? You claim now that you had
 suggestion which was not considered, yet you +2'ed a patch, by stating
 that All looks good to me!.
 
 On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com
 wrote:
  That is the beauty of the open source projects, there is always a
 smartest
  reviewer catching out the facts that you don¹t.
 
  Edgar
 
  On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:
 
 Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
 
 
 Edgar Magana
 Jul 2 8:42 AM
 
 Patch Set 13: Code-Review+2
 
 All looks good to me! I am not approving yet because Nachi was also
 reviewing this code and I would like to see his opinion as well.
 
 
 That would suggest that you were happy with what was in it. I don't
 see anything in the review comments that suggests otherwise.
 
 [1]  https://review.openstack.org/#/c/95900/
 
 On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
 edgar.mag...@workday.com
 wrote:
  This is the consequence of a proposal that is not following the
 standardized
  terminology (IETF - RFC) for any Policy-based System:
  http://tools.ietf.org/html/rfc3198
 
  Well, I did bring  this point during the Hong Kong Summit but as you
 can see
  my comments were totally ignored:
 
 
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
 Ir
 upCD9E/edit
 
  I clearly saw this kind of issues coming. Let me quote myself what I
  suggested: For instance: endpoints should be enforcement point
 
  I do not understand why GBP did not include this suggestionŠ
 
  Edgar
 
  From: Kevin Benton blak...@gmail.com
  Reply-To: OpenStack Development Mailing List (not for usage
 questions)
  openstack-dev@lists.openstack.org
  Date: Wednesday, August 6, 2014 at 10:22 AM
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
 
  Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
  forward
 
  What I was referring to was also not Keystone's definition of an
 endpoint.
  It's almost as if the term has many uses and was not invented for
 Keystone.
  :-)
 
  http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
 
  Did a similar discussion occur when Heat wanted to use the word
 'template'
  since this was clearly already in use by Horizon?
 
  On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/06/2014 02:12 AM, Kevin Benton wrote:
 
  Given that, pointing to the Nova parity work seems a bit like a red
  herring. This new API is being developed orthogonally to the
 existing
  API endpoints
 
 
  You see how you used the term endpoints there? :P
 
  -jay
 
  ___
  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] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
Ivar,

You are totally right. I just want to clarify that I haven’t express any 
disagreement on the plugin, I actually (as Sumit mentioned) +2 this patch 
before. I just pointed our that I have expressed previously that GBP should use 
the standard Policy Terminology. I did not push hard enough at the right time 
because I consider it a minor thing but Jay has a valid point and I think it 
has to be reconsidered IMHO.

Let’s be careful with our public statements!

Edgar

From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 2:52 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of 
concerns was the BP approval. The fact that it has been approved after many 
proposals and reviews means that a community effort wanted the GBP to be 
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your 
disagreement! I'm just saying that it should be expressed differently (a BP to 
propose your model in K?). Otherwise, the whole BP process becomes just 
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.

On Aug 6, 2014 11:00 PM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote:
Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 1:41 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, Sumit Naiksatam 
sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote:

Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com
wrote:
 That is the beauty of the open source projects, there is always a
smartest
 reviewer catching out the facts that you don¹t.

 Edgar

 On 8/6/14, 10:55 AM, Sumit Naiksatam 
 sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:

https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
Ir
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Robert Kukura

On 8/4/14, 4:27 PM, Mark McClain wrote:

All-

tl;dr

* Group Based Policy API is the kind of experimentation we be should 
attempting.

* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.
The disconnect here is that the Neutron group-based policy sub-team that 
has been implementing this feature for Juno does not see this work as an 
experiment to gather data, but rather as an important innovative feature 
to put in the hands of early adopters in Juno and into widespread 
deployment with a stable API as early as Kilo.


The group-based policy BP approved for Juno addresses the critical need 
for a more usable, declarative, intent-based interface for cloud 
application developers and deployers, that can co-exist with Neutron's 
current networking-hardware-oriented API and work nicely with all 
existing core plugins. Additionally, we believe that this declarative 
approach is what is needed to properly integrate advanced services into 
Neutron, and will go a long way towards resolving the difficulties so 
far trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current 
Neutron model.


Like any new service API in Neutron, the initial group policy API 
release will be subject to incompatible changes before being declared 
stable, and hence would be labeled experimental in Juno. This does 
not mean that it is an experiment where to fail fast is an acceptable 
outcome. The sub-team's goal is to stabilize the group policy API as 
quickly as possible,  making any needed changes based on early user and 
operator experience.


The L and M cycles that Mark suggests below to revisit the status are 
a completely different time frame. By the L or M cycle, we should be 
working on a new V3 Neutron API that pulls these APIs together into a 
more cohesive core API. We will not be in a position to do this properly 
without the experience of using the proposed group policy extension with 
the V2 Neutron API in production.


If we were failing miserably, or if serious technical issues were being 
identified with the patches, some delay might make sense. But, other 
than Mark's -2 blocking the initial patches from merging, we are on 
track to complete the planned work in Juno.


-Bob



Why this email?
---
Our community has been discussing and working on Group Based Policy 
(GBP) for many months.  I think the discussion has reached a point 
where we need to openly discuss a few issues before moving forward.  I 
recognize that this discussion could create frustration for those who 
have invested significant time and energy, but the reality is we need 
ensure we are making decisions that benefit all members of our 
community (users, operators, developers and vendors).


Experimentation

I like that as a community we are exploring alternate APIs.  The 
process of exploring via real user experimentation can produce 
valuable results.  A good experiment should be designed to fail fast 
to enable further trials via rapid iteration.


Merging large changes into the master branch is the exact opposite of 
failing fast.


The master branch deliberately favors small iterative changes over 
time.  Releasing a new version of the proposed API every six months 
limits our ability to learn and make adjustments.


In the past, we've released LBaaS, FWaaS, and VPNaaS as experimental 
APIs.  The results have been very mixed as operators either shy away 
from testing/offering the API or embrace the API with the expectation 
that the community will provide full API support and migration.  In 
both cases, the experiment fails because we either could not get the 
data we need or are unable to make significant changes without 
accepting a non-trivial amount of technical debt via migrations or 
draft API support.


Next Steps
--
Previously, the GPB subteam used a Github account to host the 
development, but the workflows and tooling do not align with 
OpenStack's development model. I'd like to see us create a group based 
policy project in StackForge.  StackForge will host the code and 
enable us to follow the same open review and QA processes we use in 
the main project while we are developing and testing the API. The 
infrastructure there will benefit us as we will have a separate review 
velocity and can frequently publish libraries to PyPI.  From a 
technical perspective, the 13 new entities in GPB [1] do not require 
any changes to internal Neutron data structures.  The docs[2] also 
suggest that an external plugin or service would work to make it 
easier to speed development.


End State
-
APIs require time to fully bake and right now it is too early to know 
the final outcome.  Using StackForge will allow the team to retain all 
of its options including: merging the code into Neutron, adopting the 
repository as sub-project of the Network Program, leaving the project 
in StackForge project or 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Gary Kotton
Hi,
Is there any description of how this will be consumed by Nova. My concern is 
this code landing there.
Thanks
Gary

From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

On 8/4/14, 4:27 PM, Mark McClain wrote:
All-

tl;dr

* Group Based Policy API is the kind of experimentation we be should attempting.
* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.
The disconnect here is that the Neutron group-based policy sub-team that has 
been implementing this feature for Juno does not see this work as an experiment 
to gather data, but rather as an important innovative feature to put in the 
hands of early adopters in Juno and into widespread deployment with a stable 
API as early as Kilo.

The group-based policy BP approved for Juno addresses the critical need for a 
more usable, declarative, intent-based interface for cloud application 
developers and deployers, that can co-exist with Neutron's current 
networking-hardware-oriented API and work nicely with all existing core 
plugins. Additionally, we believe that this declarative approach is what is 
needed to properly integrate advanced services into Neutron, and will go a long 
way towards resolving the difficulties so far trying to integrate LBaaS, FWaaS, 
and VPNaaS APIs into the current Neutron model.

Like any new service API in Neutron, the initial group policy API release will 
be subject to incompatible changes before being declared stable, and hence 
would be labeled experimental in Juno. This does not mean that it is an 
experiment where to fail fast is an acceptable outcome. The sub-team's goal 
is to stabilize the group policy API as quickly as possible,  making any needed 
changes based on early user and operator experience.

The L and M cycles that Mark suggests below to revisit the status are a 
completely different time frame. By the L or M cycle, we should be working on a 
new V3 Neutron API that pulls these APIs together into a more cohesive core 
API. We will not be in a position to do this properly without the experience of 
using the proposed group policy extension with the V2 Neutron API in production.

If we were failing miserably, or if serious technical issues were being 
identified with the patches, some delay might make sense. But, other than 
Mark's -2 blocking the initial patches from merging, we are on track to 
complete the planned work in Juno.

-Bob


Why this email?
---
Our community has been discussing and working on Group Based Policy (GBP) for 
many months.  I think the discussion has reached a point where we need to 
openly discuss a few issues before moving forward.  I recognize that this 
discussion could create frustration for those who have invested significant 
time and energy, but the reality is we need ensure we are making decisions that 
benefit all members of our community (users, operators, developers and vendors).

Experimentation

I like that as a community we are exploring alternate APIs.  The process of 
exploring via real user experimentation can produce valuable results.  A good 
experiment should be designed to fail fast to enable further trials via rapid 
iteration.

Merging large changes into the master branch is the exact opposite of failing 
fast.

The master branch deliberately favors small iterative changes over time.  
Releasing a new version of the proposed API every six months limits our ability 
to learn and make adjustments.

In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.  The 
results have been very mixed as operators either shy away from testing/offering 
the API or embrace the API with the expectation that the community will provide 
full API support and migration.  In both cases, the experiment fails because we 
either could not get the data we need or are unable to make significant changes 
without accepting a non-trivial amount of technical debt via migrations or 
draft API support.

Next Steps
--
Previously, the GPB subteam used a Github account to host the development, but 
the workflows and tooling do not align with OpenStack's development model. I’d 
like to see us create a group based policy project in StackForge.  StackForge 
will host the code and enable us to follow the same open review and QA 
processes we use in the main project while we are developing and testing the 
API. The infrastructure there will benefit us as we will have a separate review 
velocity and can frequently publish libraries to PyPI.  From a technical 
perspective, the 13 new entities in GPB [1] do not require any changes

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Robert Kukura


On 8/5/14, 11:04 AM, Gary Kotton wrote:

Hi,
Is there any description of how this will be consumed by Nova. My 
concern is this code landing there.

Hi Gary,

Initially, an endpoint's port_id is passed to Nova using nova boot ... 
--nic port-id=port-uuid ..., requiring no changes to Nova. Later, 
slight enhancements to Nova would allow using commands such as nova 
boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic 
epg-id=endpoint-group-uuid 


-Bob

Thanks
Gary

From: Robert Kukura kuk...@noironetworks.com 
mailto:kuk...@noironetworks.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org

Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way 
forward


On 8/4/14, 4:27 PM, Mark McClain wrote:

All-

tl;dr

* Group Based Policy API is the kind of experimentation we be should 
attempting.

* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.
The disconnect here is that the Neutron group-based policy sub-team 
that has been implementing this feature for Juno does not see this 
work as an experiment to gather data, but rather as an important 
innovative feature to put in the hands of early adopters in Juno and 
into widespread deployment with a stable API as early as Kilo.


The group-based policy BP approved for Juno addresses the critical 
need for a more usable, declarative, intent-based interface for cloud 
application developers and deployers, that can co-exist with Neutron's 
current networking-hardware-oriented API and work nicely with all 
existing core plugins. Additionally, we believe that this declarative 
approach is what is needed to properly integrate advanced services 
into Neutron, and will go a long way towards resolving the 
difficulties so far trying to integrate LBaaS, FWaaS, and VPNaaS APIs 
into the current Neutron model.


Like any new service API in Neutron, the initial group policy API 
release will be subject to incompatible changes before being declared 
stable, and hence would be labeled experimental in Juno. This does 
not mean that it is an experiment where to fail fast is an 
acceptable outcome. The sub-team's goal is to stabilize the group 
policy API as quickly as possible,  making any needed changes based on 
early user and operator experience.


The L and M cycles that Mark suggests below to revisit the status 
are a completely different time frame. By the L or M cycle, we should 
be working on a new V3 Neutron API that pulls these APIs together into 
a more cohesive core API. We will not be in a position to do this 
properly without the experience of using the proposed group policy 
extension with the V2 Neutron API in production.


If we were failing miserably, or if serious technical issues were 
being identified with the patches, some delay might make sense. But, 
other than Mark's -2 blocking the initial patches from merging, we are 
on track to complete the planned work in Juno.


-Bob



Why this email?
---
Our community has been discussing and working on Group Based Policy 
(GBP) for many months.  I think the discussion has reached a point 
where we need to openly discuss a few issues before moving forward. 
 I recognize that this discussion could create frustration for those 
who have invested significant time and energy, but the reality is we 
need ensure we are making decisions that benefit all members of our 
community (users, operators, developers and vendors).


Experimentation

I like that as a community we are exploring alternate APIs.  The 
process of exploring via real user experimentation can produce 
valuable results.  A good experiment should be designed to fail fast 
to enable further trials via rapid iteration.


Merging large changes into the master branch is the exact opposite of 
failing fast.


The master branch deliberately favors small iterative changes over 
time.  Releasing a new version of the proposed API every six months 
limits our ability to learn and make adjustments.


In the past, we've released LBaaS, FWaaS, and VPNaaS as experimental 
APIs.  The results have been very mixed as operators either shy away 
from testing/offering the API or embrace the API with the expectation 
that the community will provide full API support and migration.  In 
both cases, the experiment fails because we either could not get the 
data we need or are unable to make significant changes without 
accepting a non-trivial amount of technical debt via migrations or 
draft API support.


Next Steps
--
Previously, the GPB subteam used a Github account to host the 
development, but the workflows and tooling do not align with 
OpenStack's development model. I'd like to see us create a group 
based policy project in StackForge

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Gary Kotton
Ok, thanks for the clarification. This means that it will not be done 
automagically as it is today – the tenant will need to create a Neutron port 
and then pass that through.
Thanks
Gary

From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, August 5, 2014 at 8:13 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


On 8/5/14, 11:04 AM, Gary Kotton wrote:
Hi,
Is there any description of how this will be consumed by Nova. My concern is 
this code landing there.
Hi Gary,

Initially, an endpoint's port_id is passed to Nova using nova boot ... --nic 
port-id=port-uuid ..., requiring no changes to Nova. Later, slight 
enhancements to Nova would allow using commands such as nova boot ... --nic 
ep-id=endpoint-uuid ... or nova boot ... --nic epg-id=endpoint-group-uuid 


-Bob
Thanks
Gary

From: Robert Kukura kuk...@noironetworks.commailto:kuk...@noironetworks.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

On 8/4/14, 4:27 PM, Mark McClain wrote:
All-

tl;dr

* Group Based Policy API is the kind of experimentation we be should attempting.
* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.
The disconnect here is that the Neutron group-based policy sub-team that has 
been implementing this feature for Juno does not see this work as an experiment 
to gather data, but rather as an important innovative feature to put in the 
hands of early adopters in Juno and into widespread deployment with a stable 
API as early as Kilo.

The group-based policy BP approved for Juno addresses the critical need for a 
more usable, declarative, intent-based interface for cloud application 
developers and deployers, that can co-exist with Neutron's current 
networking-hardware-oriented API and work nicely with all existing core 
plugins. Additionally, we believe that this declarative approach is what is 
needed to properly integrate advanced services into Neutron, and will go a long 
way towards resolving the difficulties so far trying to integrate LBaaS, FWaaS, 
and VPNaaS APIs into the current Neutron model.

Like any new service API in Neutron, the initial group policy API release will 
be subject to incompatible changes before being declared stable, and hence 
would be labeled experimental in Juno. This does not mean that it is an 
experiment where to fail fast is an acceptable outcome. The sub-team's goal 
is to stabilize the group policy API as quickly as possible,  making any needed 
changes based on early user and operator experience.

The L and M cycles that Mark suggests below to revisit the status are a 
completely different time frame. By the L or M cycle, we should be working on a 
new V3 Neutron API that pulls these APIs together into a more cohesive core 
API. We will not be in a position to do this properly without the experience of 
using the proposed group policy extension with the V2 Neutron API in production.

If we were failing miserably, or if serious technical issues were being 
identified with the patches, some delay might make sense. But, other than 
Mark's -2 blocking the initial patches from merging, we are on track to 
complete the planned work in Juno.

-Bob


Why this email?
---
Our community has been discussing and working on Group Based Policy (GBP) for 
many months.  I think the discussion has reached a point where we need to 
openly discuss a few issues before moving forward.  I recognize that this 
discussion could create frustration for those who have invested significant 
time and energy, but the reality is we need ensure we are making decisions that 
benefit all members of our community (users, operators, developers and vendors).

Experimentation

I like that as a community we are exploring alternate APIs.  The process of 
exploring via real user experimentation can produce valuable results.  A good 
experiment should be designed to fail fast to enable further trials via rapid 
iteration.

Merging large changes into the master branch is the exact opposite of failing 
fast.

The master branch deliberately favors small iterative changes over time.  
Releasing a new version of the proposed API every six months limits our ability 
to learn and make adjustments.

In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.  The 
results have been very mixed as operators either shy away from testing/offering 
the API or embrace the API

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Robert Kukura


On 8/5/14, 1:23 PM, Gary Kotton wrote:
Ok, thanks for the clarification. This means that it will not be done 
automagically as it is today -- the tenant will need to create a 
Neutron port and then pass that through.
Not quite. Using the group policy API, the port will be created 
implicitly when the endpoint is created (unless an existing port_id is 
passed explicitly). All the user will need to do is obtain the port_id 
value from the endpoint and pass this to nova.


The goal is to make passing --nic epg-id=endpoint-group-id just as 
automatic as passing --nic net-id=network-uuid. Code in Nova's 
Neutron integration would handle the epg-id by passing it to 
create_endpoint, and then using the port_id that is returned in the result.


-Bob

Thanks
Gary

From: Robert Kukura kuk...@noironetworks.com 
mailto:kuk...@noironetworks.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org

Date: Tuesday, August 5, 2014 at 8:13 PM
To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way 
forward



On 8/5/14, 11:04 AM, Gary Kotton wrote:

Hi,
Is there any description of how this will be consumed by Nova. My 
concern is this code landing there.

Hi Gary,

Initially, an endpoint's port_id is passed to Nova using nova boot 
... --nic port-id=port-uuid ..., requiring no changes to Nova. 
Later, slight enhancements to Nova would allow using commands such as 
nova boot ... --nic ep-id=endpoint-uuid ... or nova boot ... 
--nic epg-id=endpoint-group-uuid 


-Bob

Thanks
Gary

From: Robert Kukura kuk...@noironetworks.com 
mailto:kuk...@noironetworks.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org

Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way 
forward


On 8/4/14, 4:27 PM, Mark McClain wrote:

All-

tl;dr

* Group Based Policy API is the kind of experimentation we be should 
attempting.

* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.
The disconnect here is that the Neutron group-based policy sub-team 
that has been implementing this feature for Juno does not see this 
work as an experiment to gather data, but rather as an important 
innovative feature to put in the hands of early adopters in Juno and 
into widespread deployment with a stable API as early as Kilo.


The group-based policy BP approved for Juno addresses the critical 
need for a more usable, declarative, intent-based interface for cloud 
application developers and deployers, that can co-exist with 
Neutron's current networking-hardware-oriented API and work nicely 
with all existing core plugins. Additionally, we believe that this 
declarative approach is what is needed to properly integrate advanced 
services into Neutron, and will go a long way towards resolving the 
difficulties so far trying to integrate LBaaS, FWaaS, and VPNaaS APIs 
into the current Neutron model.


Like any new service API in Neutron, the initial group policy API 
release will be subject to incompatible changes before being declared 
stable, and hence would be labeled experimental in Juno. This 
does not mean that it is an experiment where to fail fast is an 
acceptable outcome. The sub-team's goal is to stabilize the group 
policy API as quickly as possible,  making any needed changes based 
on early user and operator experience.


The L and M cycles that Mark suggests below to revisit the status 
are a completely different time frame. By the L or M cycle, we should 
be working on a new V3 Neutron API that pulls these APIs together 
into a more cohesive core API. We will not be in a position to do 
this properly without the experience of using the proposed group 
policy extension with the V2 Neutron API in production.


If we were failing miserably, or if serious technical issues were 
being identified with the patches, some delay might make sense. But, 
other than Mark's -2 blocking the initial patches from merging, we 
are on track to complete the planned work in Juno.


-Bob



Why this email?
---
Our community has been discussing and working on Group Based Policy 
(GBP) for many months.  I think the discussion has reached a point 
where we need to openly discuss a few issues before moving forward. 
 I recognize that this discussion could create frustration for those 
who have invested significant time and energy, but the reality is we 
need ensure we are making decisions that benefit all members of our 
community (users, operators, developers and vendors).


Experimentation

I like that as a community we are exploring alternate APIs.  The 
process of exploring via real user

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Russell Bryant
On 08/05/2014 01:23 PM, Gary Kotton wrote:
 Ok, thanks for the clarification. This means that it will not be done
 automagically as it is today – the tenant will need to create a Neutron
 port and then pass that through.

FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
like to get rid of automatic port creation, but can't do that in the
current stable API.

-- 
Russell Bryant

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Jay Pipes

On 08/05/2014 01:13 PM, Robert Kukura wrote:


On 8/5/14, 11:04 AM, Gary Kotton wrote:

Hi,
Is there any description of how this will be consumed by Nova. My
concern is this code landing there.

Hi Gary,

Initially, an endpoint's port_id is passed to Nova using nova boot ...
--nic port-id=port-uuid ..., requiring no changes to Nova. Later,
slight enhancements to Nova would allow using commands such as nova
boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
epg-id=endpoint-group-uuid 


Hi Bob,

How exactly is the above a friendlier API for the main user of Neutron, 
which is Nova? I thought one of the main ideas behind the GBP stuff was 
to create a more declarative and intuitive API for users of Neutron -- 
i.e. Nova -- to use in constructing needed networking objects. The above 
just seems to me to be exchanging one low-level object (port) with 
another low-level object (endpoint or endpoint group)?


Perhaps the disconnect is due to the term endpoint being used, which, 
everywhere else in the OpenStack universe, means something entirely 
different from GBP.


I guess, based on my understanding of the *intent* of the GBP API, I 
would have expected an API more like:


 nova boot ... --networking-template UUID

where --networking-template would refer to a network, subnet topology, 
IP assignment policy, collection of security groups and firewall 
policies that the tenant had established prior to booting an instance... 
thereby making the API more intuitive and less cluttered.


Or is it that I just don't understand this new endpoint terminology?

Best,
-jay

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Kevin Benton
Specifying an endpoint group would achieve the --networking-template
effects you described. The endpoint group would have all of the security
policies, IP allocation policies, connectivity policies, etc. already setup.


On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/05/2014 01:13 PM, Robert Kukura wrote:


 On 8/5/14, 11:04 AM, Gary Kotton wrote:

 Hi,
 Is there any description of how this will be consumed by Nova. My
 concern is this code landing there.

 Hi Gary,

 Initially, an endpoint's port_id is passed to Nova using nova boot ...
 --nic port-id=port-uuid ..., requiring no changes to Nova. Later,
 slight enhancements to Nova would allow using commands such as nova
 boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
 epg-id=endpoint-group-uuid 


 Hi Bob,

 How exactly is the above a friendlier API for the main user of Neutron,
 which is Nova? I thought one of the main ideas behind the GBP stuff was to
 create a more declarative and intuitive API for users of Neutron -- i.e.
 Nova -- to use in constructing needed networking objects. The above just
 seems to me to be exchanging one low-level object (port) with another
 low-level object (endpoint or endpoint group)?

 Perhaps the disconnect is due to the term endpoint being used, which,
 everywhere else in the OpenStack universe, means something entirely
 different from GBP.

 I guess, based on my understanding of the *intent* of the GBP API, I would
 have expected an API more like:

  nova boot ... --networking-template UUID

 where --networking-template would refer to a network, subnet topology, IP
 assignment policy, collection of security groups and firewall policies that
 the tenant had established prior to booting an instance... thereby making
 the API more intuitive and less cluttered.

 Or is it that I just don't understand this new endpoint terminology?

 Best,
 -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] Group Based Policy and the way forward

2014-08-05 Thread Jay Pipes

On 08/05/2014 03:24 PM, Kevin Benton wrote:

Specifying an endpoint group would achieve the --networking-template
effects you described. The endpoint group would have all of the security
policies, IP allocation policies, connectivity policies, etc. already setup.


OK. Is there any reason it was called an endpoint group then? Perhaps 
I am missing something, but the term endpoint is well-used and 
understood to mean something entirely different in the OpenStack 
ecosystem...


Best,
-jay


On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

On 08/05/2014 01:13 PM, Robert Kukura wrote:


On 8/5/14, 11:04 AM, Gary Kotton wrote:

Hi,
Is there any description of how this will be consumed by
Nova. My
concern is this code landing there.

Hi Gary,

Initially, an endpoint's port_id is passed to Nova using nova
boot ...
--nic port-id=port-uuid ..., requiring no changes to Nova. Later,
slight enhancements to Nova would allow using commands such as nova
boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
epg-id=endpoint-group-uuid 


Hi Bob,

How exactly is the above a friendlier API for the main user of
Neutron, which is Nova? I thought one of the main ideas behind the
GBP stuff was to create a more declarative and intuitive API for
users of Neutron -- i.e. Nova -- to use in constructing needed
networking objects. The above just seems to me to be exchanging one
low-level object (port) with another low-level object (endpoint or
endpoint group)?

Perhaps the disconnect is due to the term endpoint being used,
which, everywhere else in the OpenStack universe, means something
entirely different from GBP.

I guess, based on my understanding of the *intent* of the GBP API, I
would have expected an API more like:

  nova boot ... --networking-template UUID

where --networking-template would refer to a network, subnet
topology, IP assignment policy, collection of security groups and
firewall policies that the tenant had established prior to booting
an instance... thereby making the API more intuitive and less cluttered.

Or is it that I just don't understand this new endpoint terminology?

Best,
-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] Group Based Policy and the way forward

2014-08-05 Thread Sumit Naiksatam
That's right Kevin, EPG (and its association to the L2/3_Policy)
capture the attributes which would represent the network-template
being referenced here.

Jay, what Bob mentioned here was an option to use the endpoint as a
one-to-one replacement for the option of using a Neutron port. This is
more so in the context of providing an evolutionary path (from the way
Nova currently does it using a pre-defined port). However, if it makes
sense to make Nova aware of the EPG right at the outset, then that is
even better.

I have also noted your suggestion on clarifying the endpoint
terminology. This was already done in one of the patches you had
reviewed earlier, and will do that in the first patch as well (where
you pointed it out now).

Thanks,
~Sumit.

On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com wrote:
 Specifying an endpoint group would achieve the --networking-template effects
 you described. The endpoint group would have all of the security policies,
 IP allocation policies, connectivity policies, etc. already setup.


 On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/05/2014 01:13 PM, Robert Kukura wrote:


 On 8/5/14, 11:04 AM, Gary Kotton wrote:

 Hi,
 Is there any description of how this will be consumed by Nova. My
 concern is this code landing there.

 Hi Gary,

 Initially, an endpoint's port_id is passed to Nova using nova boot ...
 --nic port-id=port-uuid ..., requiring no changes to Nova. Later,
 slight enhancements to Nova would allow using commands such as nova
 boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
 epg-id=endpoint-group-uuid 


 Hi Bob,

 How exactly is the above a friendlier API for the main user of Neutron,
 which is Nova? I thought one of the main ideas behind the GBP stuff was to
 create a more declarative and intuitive API for users of Neutron -- i.e.
 Nova -- to use in constructing needed networking objects. The above just
 seems to me to be exchanging one low-level object (port) with another
 low-level object (endpoint or endpoint group)?

 Perhaps the disconnect is due to the term endpoint being used, which,
 everywhere else in the OpenStack universe, means something entirely
 different from GBP.

 I guess, based on my understanding of the *intent* of the GBP API, I would
 have expected an API more like:

  nova boot ... --networking-template UUID

 where --networking-template would refer to a network, subnet topology, IP
 assignment policy, collection of security groups and firewall policies that
 the tenant had established prior to booting an instance... thereby making
 the API more intuitive and less cluttered.

 Or is it that I just don't understand this new endpoint terminology?

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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Stephen Wong
Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
endpoint as an option in place of Neutron port. But if we can make Nova
EPG-aware, it would be great.


On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 That's right Kevin, EPG (and its association to the L2/3_Policy)
 capture the attributes which would represent the network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the endpoint as a
 one-to-one replacement for the option of using a Neutron port. This is
 more so in the context of providing an evolutionary path (from the way
 Nova currently does it using a pre-defined port). However, if it makes
 sense to make Nova aware of the EPG right at the outset, then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches you had
 reviewed earlier, and will do that in the first patch as well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com wrote:
  Specifying an endpoint group would achieve the --networking-template
 effects
  you described. The endpoint group would have all of the security
 policies,
  IP allocation policies, connectivity policies, etc. already setup.
 
 
  On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/05/2014 01:13 PM, Robert Kukura wrote:
 
 
  On 8/5/14, 11:04 AM, Gary Kotton wrote:
 
  Hi,
  Is there any description of how this will be consumed by Nova. My
  concern is this code landing there.
 
  Hi Gary,
 
  Initially, an endpoint's port_id is passed to Nova using nova boot ...
  --nic port-id=port-uuid ..., requiring no changes to Nova. Later,
  slight enhancements to Nova would allow using commands such as nova
  boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
  epg-id=endpoint-group-uuid 
 
 
  Hi Bob,
 
  How exactly is the above a friendlier API for the main user of Neutron,
  which is Nova? I thought one of the main ideas behind the GBP stuff was
 to
  create a more declarative and intuitive API for users of Neutron -- i.e.
  Nova -- to use in constructing needed networking objects. The above just
  seems to me to be exchanging one low-level object (port) with another
  low-level object (endpoint or endpoint group)?
 
  Perhaps the disconnect is due to the term endpoint being used, which,
  everywhere else in the OpenStack universe, means something entirely
  different from GBP.
 
  I guess, based on my understanding of the *intent* of the GBP API, I
 would
  have expected an API more like:
 
   nova boot ... --networking-template UUID
 
  where --networking-template would refer to a network, subnet topology,
 IP
  assignment policy, collection of security groups and firewall policies
 that
  the tenant had established prior to booting an instance... thereby
 making
  the API more intuitive and less cluttered.
 
  Or is it that I just don't understand this new endpoint terminology?
 
  Best,
  -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
 

 ___
 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] Group Based Policy and the way forward

2014-08-05 Thread Jay Pipes

On 08/05/2014 04:26 PM, Stephen Wong wrote:

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
endpoint as an option in place of Neutron port. But if we can make
Nova EPG-aware, it would be great.


Is anyone listening to what I'm saying? The term endpoint is obtuse 
and completely disregards the existing denotation of the word endpoint 
in use in OpenStack today.


So, we've gone ahead and replaced the term port in the caller 
interface -- which, besides being too entirely too low-level, actually 
did describe what the object was -- to using a term endpoint that 
doesn't describe even remotely what the thing is (a template for a 
collection of networking-related policies and objects) and that already 
has a well-known definition in the OpenStack ecosystem.


That is my point. That is why I brought up the comment on the original 
patch in the series that some docstrings would be helpful for those not 
entirely subscribed to the Tenets of National Dvorkinism.


These interfaces should speak plain old concepts, not networking guru 
arcanum.


Best,
-jay


On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com wrote:

That's right Kevin, EPG (and its association to the L2/3_Policy)
capture the attributes which would represent the network-template
being referenced here.

Jay, what Bob mentioned here was an option to use the endpoint as a
one-to-one replacement for the option of using a Neutron port. This is
more so in the context of providing an evolutionary path (from the way
Nova currently does it using a pre-defined port). However, if it makes
sense to make Nova aware of the EPG right at the outset, then that is
even better.

I have also noted your suggestion on clarifying the endpoint
terminology. This was already done in one of the patches you had
reviewed earlier, and will do that in the first patch as well (where
you pointed it out now).

Thanks,
~Sumit.

On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com
mailto:blak...@gmail.com wrote:
  Specifying an endpoint group would achieve the
--networking-template effects
  you described. The endpoint group would have all of the security
policies,
  IP allocation policies, connectivity policies, etc. already setup.
 
 
  On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
 
  On 08/05/2014 01:13 PM, Robert Kukura wrote:
 
 
  On 8/5/14, 11:04 AM, Gary Kotton wrote:
 
  Hi,
  Is there any description of how this will be consumed by Nova. My
  concern is this code landing there.
 
  Hi Gary,
 
  Initially, an endpoint's port_id is passed to Nova using nova
boot ...
  --nic port-id=port-uuid ..., requiring no changes to Nova.
Later,
  slight enhancements to Nova would allow using commands such as
nova
  boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
  epg-id=endpoint-group-uuid 
 
 
  Hi Bob,
 
  How exactly is the above a friendlier API for the main user of
Neutron,
  which is Nova? I thought one of the main ideas behind the GBP
stuff was to
  create a more declarative and intuitive API for users of Neutron
-- i.e.
  Nova -- to use in constructing needed networking objects. The
above just
  seems to me to be exchanging one low-level object (port) with
another
  low-level object (endpoint or endpoint group)?
 
  Perhaps the disconnect is due to the term endpoint being used,
which,
  everywhere else in the OpenStack universe, means something entirely
  different from GBP.
 
  I guess, based on my understanding of the *intent* of the GBP
API, I would
  have expected an API more like:
 
   nova boot ... --networking-template UUID
 
  where --networking-template would refer to a network, subnet
topology, IP
  assignment policy, collection of security groups and firewall
policies that
  the tenant had established prior to booting an instance...
thereby making
  the API more intuitive and less cluttered.
 
  Or is it that I just don't understand this new endpoint
terminology?
 
  Best,
  -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
 
 
 
 
  --
  Kevin Benton
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
  

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Kevin Benton
Is anyone listening to what I'm saying? The term endpoint is obtuse and
completely disregards the existing denotation of the word endpoint in use
in OpenStack today.

Sorry, I didn't understand the confusion because you didn't provide a
reference to how endpoint is used in OpenStack now. I hadn't heard the
term until this GBP work other than keystone endpoints, which have no
overlap with this. Can you provide the definition you are familiar with so
someone can explain the difference?


On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/05/2014 04:26 PM, Stephen Wong wrote:

 Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
 integration, and the preliminary idea, as Bob alluded to, is to add
 endpoint as an option in place of Neutron port. But if we can make
 Nova EPG-aware, it would be great.


 Is anyone listening to what I'm saying? The term endpoint is obtuse and
 completely disregards the existing denotation of the word endpoint in use
 in OpenStack today.

 So, we've gone ahead and replaced the term port in the caller interface
 -- which, besides being too entirely too low-level, actually did describe
 what the object was -- to using a term endpoint that doesn't describe
 even remotely what the thing is (a template for a collection of
 networking-related policies and objects) and that already has a well-known
 definition in the OpenStack ecosystem.

 That is my point. That is why I brought up the comment on the original
 patch in the series that some docstrings would be helpful for those not
 entirely subscribed to the Tenets of National Dvorkinism.

 These interfaces should speak plain old concepts, not networking guru
 arcanum.

 Best,
 -jay

  On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
 sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com wrote:

 That's right Kevin, EPG (and its association to the L2/3_Policy)
 capture the attributes which would represent the network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the endpoint as a
 one-to-one replacement for the option of using a Neutron port. This is
 more so in the context of providing an evolutionary path (from the way
 Nova currently does it using a pre-defined port). However, if it makes
 sense to make Nova aware of the EPG right at the outset, then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches you had
 reviewed earlier, and will do that in the first patch as well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com
 mailto:blak...@gmail.com wrote:
   Specifying an endpoint group would achieve the
 --networking-template effects
   you described. The endpoint group would have all of the security
 policies,
   IP allocation policies, connectivity policies, etc. already setup.
  
  
   On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
  
   On 08/05/2014 01:13 PM, Robert Kukura wrote:
  
  
   On 8/5/14, 11:04 AM, Gary Kotton wrote:
  
   Hi,
   Is there any description of how this will be consumed by Nova.
 My
   concern is this code landing there.
  
   Hi Gary,
  
   Initially, an endpoint's port_id is passed to Nova using nova
 boot ...
   --nic port-id=port-uuid ..., requiring no changes to Nova.
 Later,
   slight enhancements to Nova would allow using commands such as
 nova
   boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
   epg-id=endpoint-group-uuid 
  
  
   Hi Bob,
  
   How exactly is the above a friendlier API for the main user of
 Neutron,
   which is Nova? I thought one of the main ideas behind the GBP
 stuff was to
   create a more declarative and intuitive API for users of Neutron
 -- i.e.
   Nova -- to use in constructing needed networking objects. The
 above just
   seems to me to be exchanging one low-level object (port) with
 another
   low-level object (endpoint or endpoint group)?
  
   Perhaps the disconnect is due to the term endpoint being used,
 which,
   everywhere else in the OpenStack universe, means something
 entirely
   different from GBP.
  
   I guess, based on my understanding of the *intent* of the GBP
 API, I would
   have expected an API more like:
  
nova boot ... --networking-template UUID
  
   where --networking-template would refer to a network, subnet
 topology, IP
   assignment policy, collection of security groups and firewall
 policies that
   the tenant had established prior to booting an instance...
 thereby making
   the API more intuitive and less cluttered.
 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Sumit Naiksatam
On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/05/2014 04:26 PM, Stephen Wong wrote:

 Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
 integration, and the preliminary idea, as Bob alluded to, is to add
 endpoint as an option in place of Neutron port. But if we can make
 Nova EPG-aware, it would be great.


 Is anyone listening to what I'm saying? The term endpoint is obtuse and
 completely disregards the existing denotation of the word endpoint in use
 in OpenStack today.


Yes, listening, absolutely. I acknowledged your point in this thread
as well as on the review. Your suggestion on the thread seemed to be
to document this better and clarify. Is that sufficient for moving
forward, or are you thinking something else?

 So, we've gone ahead and replaced the term port in the caller interface --
 which, besides being too entirely too low-level, actually did describe what
 the object was -- to using a term endpoint that doesn't describe even
 remotely what the thing is (a template for a collection of
 networking-related policies and objects) and that already has a well-known
 definition in the OpenStack ecosystem.


Couple of things -

The endpoint, as is being used in this context, does not refer to
the template that you are referring to (if I understand you
correctly). The template in some ways is analogous to the endpoint
group (or EPG), and is defined as a collection of endpoints. Kevin,
Stephen, and I, have been alluding to that in this thread earlier.

Why endpoint? The thinking, among the people discussing this, was
that it needs to be something more abstract than the very specific
network port terminology, and something with which can associate
policies and labels/tags. I am not advocating that this is the perfect
naming convention, and I do appreciate the concern that there is
overlap with an endpoint being used in a different context elsewhere
in OpenStack. This overlap however escaped everybody's attention until
it manifested in the code and your review (after having gone through
review in two design summit sessions and being in discussion over
several months).

 That is my point. That is why I brought up the comment on the original patch
 in the series that some docstrings would be helpful for those not entirely
 subscribed to the Tenets of National Dvorkinism.

 These interfaces should speak plain old concepts, not networking guru
 arcanum.

 Best,
 -jay

 On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
 sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com wrote:

 That's right Kevin, EPG (and its association to the L2/3_Policy)
 capture the attributes which would represent the network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the endpoint as a
 one-to-one replacement for the option of using a Neutron port. This is
 more so in the context of providing an evolutionary path (from the way
 Nova currently does it using a pre-defined port). However, if it makes
 sense to make Nova aware of the EPG right at the outset, then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches you had
 reviewed earlier, and will do that in the first patch as well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com
 mailto:blak...@gmail.com wrote:
   Specifying an endpoint group would achieve the
 --networking-template effects
   you described. The endpoint group would have all of the security
 policies,
   IP allocation policies, connectivity policies, etc. already setup.
  
  
   On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
  
   On 08/05/2014 01:13 PM, Robert Kukura wrote:
  
  
   On 8/5/14, 11:04 AM, Gary Kotton wrote:
  
   Hi,
   Is there any description of how this will be consumed by Nova.
 My
   concern is this code landing there.
  
   Hi Gary,
  
   Initially, an endpoint's port_id is passed to Nova using nova
 boot ...
   --nic port-id=port-uuid ..., requiring no changes to Nova.
 Later,
   slight enhancements to Nova would allow using commands such as
 nova
   boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
   epg-id=endpoint-group-uuid 
  
  
   Hi Bob,
  
   How exactly is the above a friendlier API for the main user of
 Neutron,
   which is Nova? I thought one of the main ideas behind the GBP
 stuff was to
   create a more declarative and intuitive API for users of Neutron
 -- i.e.
   Nova -- to use in constructing needed networking objects. The
 above just
   seems to me to be exchanging one low-level object (port) with
 another
   low-level 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Jay Pipes

On 08/05/2014 05:22 PM, Kevin Benton wrote:

 Is anyone listening to what I'm saying? The term endpoint is obtuse
and completely disregards the existing denotation of the word endpoint
in use in OpenStack today.

Sorry, I didn't understand the confusion because you didn't provide a
reference to how endpoint is used in OpenStack now. I hadn't heard the
term until this GBP work other than keystone endpoints, which have no
overlap with this. Can you provide the definition you are familiar with
so someone can explain the difference?


Yes, a Keystone endpoint, which exists in the service catalog that every 
single token sent to and from any OpenStack service.


You are correct that there is no overlap with the GBP concept of 
endpoint. But, I guess I'm surprised nobody brought this up when 
discussing the proposed GBP API extensions to Neutron... since the 
endpoint has been a part of the Keystone service catalog API for years.


It would be like if the GBP API came up with a new resource called 
project or tenant and expected everyone to just understand that this 
new project resource had nothing to do with the project concept that 
is used throughout the other APIs...


Anyway, sorry if I'm just blowing off some steam here... it's my fault 
for not paying more attention to this earlier on. But this point goes 
directly to the discussion that Mark McClain and Bob were having about 
whether to let an major API extension like this bake somewhere outside 
of Neutron vs. baking inside Neutron ala VPNaaS, LBaaS, etc.


OK, steam has been blown off, sorry for the partially tangential thread.

-jay



On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

On 08/05/2014 04:26 PM, Stephen Wong wrote:

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
endpoint as an option in place of Neutron port. But if we can make
Nova EPG-aware, it would be great.


Is anyone listening to what I'm saying? The term endpoint is
obtuse and completely disregards the existing denotation of the word
endpoint in use in OpenStack today.

So, we've gone ahead and replaced the term port in the caller
interface -- which, besides being too entirely too low-level,
actually did describe what the object was -- to using a term
endpoint that doesn't describe even remotely what the thing is (a
template for a collection of networking-related policies and
objects) and that already has a well-known definition in the
OpenStack ecosystem.

That is my point. That is why I brought up the comment on the
original patch in the series that some docstrings would be helpful
for those not entirely subscribed to the Tenets of National Dvorkinism.

These interfaces should speak plain old concepts, not networking
guru arcanum.

Best,
-jay

On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com
mailto:sumitnaiksatam@gmail.__com
mailto:sumitnaiksa...@gmail.com wrote:

 That's right Kevin, EPG (and its association to the
L2/3_Policy)
 capture the attributes which would represent the
network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the
endpoint as a
 one-to-one replacement for the option of using a Neutron
port. This is
 more so in the context of providing an evolutionary path
(from the way
 Nova currently does it using a pre-defined port). However,
if it makes
 sense to make Nova aware of the EPG right at the outset,
then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches
you had
 reviewed earlier, and will do that in the first patch as
well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton
blak...@gmail.com mailto:blak...@gmail.com
 mailto:blak...@gmail.com mailto:blak...@gmail.com wrote:
   Specifying an endpoint group would achieve the
 --networking-template effects
   you described. The endpoint group would have all of the
security
 policies,
   IP allocation policies, connectivity policies, etc.
already setup.
  
  
   On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes
jaypi...@gmail.com mailto:jaypi...@gmail.com
 mailto:jaypi...@gmail.com mailto:jaypi...@gmail.com wrote:
  
   On 08/05/2014 01:13 PM, Robert Kukura wrote:
  
 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Kevin Benton
That makes sense. It's not quite a fair analogy though to compare to
reintroducing projects or tenants because Keystone endpoints aren't
'user-facing' so to speak. i.e. a regular user (application deployer,
instance operator, etc) should never have to see or understand the purpose
of a Keystone endpoint.
On Aug 5, 2014 3:53 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/05/2014 05:22 PM, Kevin Benton wrote:

  Is anyone listening to what I'm saying? The term endpoint is obtuse
 and completely disregards the existing denotation of the word endpoint
 in use in OpenStack today.

 Sorry, I didn't understand the confusion because you didn't provide a
 reference to how endpoint is used in OpenStack now. I hadn't heard the
 term until this GBP work other than keystone endpoints, which have no
 overlap with this. Can you provide the definition you are familiar with
 so someone can explain the difference?


 Yes, a Keystone endpoint, which exists in the service catalog that every
 single token sent to and from any OpenStack service.

 You are correct that there is no overlap with the GBP concept of endpoint.
 But, I guess I'm surprised nobody brought this up when discussing the
 proposed GBP API extensions to Neutron... since the endpoint has been a
 part of the Keystone service catalog API for years.

 It would be like if the GBP API came up with a new resource called
 project or tenant and expected everyone to just understand that this
 new project resource had nothing to do with the project concept that is
 used throughout the other APIs...

 Anyway, sorry if I'm just blowing off some steam here... it's my fault for
 not paying more attention to this earlier on. But this point goes directly
 to the discussion that Mark McClain and Bob were having about whether to
 let an major API extension like this bake somewhere outside of Neutron vs.
 baking inside Neutron ala VPNaaS, LBaaS, etc.

 OK, steam has been blown off, sorry for the partially tangential thread.

 -jay


  On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:

 On 08/05/2014 04:26 PM, Stephen Wong wrote:

 Agreed with Kevin and Sumit here. As a subgroup we talked about
 Nova
 integration, and the preliminary idea, as Bob alluded to, is to
 add
 endpoint as an option in place of Neutron port. But if we can
 make
 Nova EPG-aware, it would be great.


 Is anyone listening to what I'm saying? The term endpoint is
 obtuse and completely disregards the existing denotation of the word
 endpoint in use in OpenStack today.

 So, we've gone ahead and replaced the term port in the caller
 interface -- which, besides being too entirely too low-level,
 actually did describe what the object was -- to using a term
 endpoint that doesn't describe even remotely what the thing is (a
 template for a collection of networking-related policies and
 objects) and that already has a well-known definition in the
 OpenStack ecosystem.

 That is my point. That is why I brought up the comment on the
 original patch in the series that some docstrings would be helpful
 for those not entirely subscribed to the Tenets of National
 Dvorkinism.

 These interfaces should speak plain old concepts, not networking
 guru arcanum.

 Best,
 -jay

 On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
 sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com
 mailto:sumitnaiksatam@gmail.__com
 mailto:sumitnaiksa...@gmail.com wrote:

  That's right Kevin, EPG (and its association to the
 L2/3_Policy)
  capture the attributes which would represent the
 network-template
  being referenced here.

  Jay, what Bob mentioned here was an option to use the
 endpoint as a
  one-to-one replacement for the option of using a Neutron
 port. This is
  more so in the context of providing an evolutionary path
 (from the way
  Nova currently does it using a pre-defined port). However,
 if it makes
  sense to make Nova aware of the EPG right at the outset,
 then that is
  even better.

  I have also noted your suggestion on clarifying the
 endpoint
  terminology. This was already done in one of the patches
 you had
  reviewed earlier, and will do that in the first patch as
 well (where
  you pointed it out now).

  Thanks,
  ~Sumit.

  On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton
 blak...@gmail.com mailto:blak...@gmail.com
  mailto:blak...@gmail.com mailto:blak...@gmail.com
 wrote:
Specifying an endpoint group would achieve the
  --networking-template effects
you described. The endpoint group would have all of the

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Joe Gordon
On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura kuk...@noironetworks.com
wrote:

  On 8/4/14, 4:27 PM, Mark McClain wrote:

 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.

 The disconnect here is that the Neutron group-based policy sub-team that
 has been implementing this feature for Juno does not see this work as an
 experiment to gather data, but rather as an important innovative feature to
 put in the hands of early adopters in Juno and into widespread deployment
 with a stable API as early as Kilo.


 The group-based policy BP approved for Juno addresses the critical need
 for a more usable, declarative, intent-based interface for cloud
 application developers and deployers, that can co-exist with Neutron's
 current networking-hardware-oriented API and work nicely with all existing
 core plugins. Additionally, we believe that this declarative approach is
 what is needed to properly integrate advanced services into Neutron, and
 will go a long way towards resolving the difficulties so far trying to
 integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron model.

 Like any new service API in Neutron, the initial group policy API release
 will be subject to incompatible changes before being declared stable, and
 hence would be labeled experimental in Juno. This does not mean that it
 is an experiment where to fail fast is an acceptable outcome. The
 sub-team's goal is to stabilize the group policy API as quickly as
 possible,  making any needed changes based on early user and operator
 experience.

 The L and M cycles that Mark suggests below to revisit the status are a
 completely different time frame. By the L or M cycle, we should be working
 on a new V3 Neutron API that pulls these APIs together into a more cohesive
 core API. We will not be in a position to do this properly without the
 experience of using the proposed group policy extension with the V2 Neutron
 API in production.


 If we were failing miserably, or if serious technical issues were being
 identified with the patches, some delay might make sense. But, other than
 Mark's -2 blocking the initial patches from merging, we are on track to
 complete the planned work in Juno.

 -Bob



As a member of nova-core, I find this whole discussion very startling.
Putting aside the concerns over technical details and the pain of having in
tree experimental APIs (such as nova v3 API), neutron still isn't the
de-facto networking solution from nova's perspective and it won't be until
neutron has feature and performance parity with nova-network. In fact due
to the slow maturation of neutron, nova has moved nova-network from
'frozen' to open for development (with a few caveats).  So unless this new
API directly solves some of the gaps in [0], I see no reason to push this
into Juno. Juno hardly seems to be the appropriate time to introduce a new
not-so-stable API; Juno is the time to address all the gaps [0] and hit
feature and performance parity with nova-network.


[0]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage


best,
Joe






 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy (GBP)
 for many months.  I think the discussion has reached a point where we need
 to openly discuss a few issues before moving forward.  I recognize that
 this discussion could create frustration for those who have invested
 significant time and energy, but the reality is we need ensure we are
 making decisions that benefit all members of our community (users,
 operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.  A
 good experiment should be designed to fail fast to enable further trials
 via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
  Releasing a new version of the proposed API every six months limits our
 ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.
  The results have been very mixed as operators either shy away from
 testing/offering the API or embrace the API with the expectation that the
 community will provide full API support and migration.  In both cases, the
 experiment fails because we either could not get the data we need or are
 unable to make significant changes without accepting a non-trivial amount
 of technical debt via migrations or draft API support.

 Next Steps
 --
 Previously, the GPB subteam used a Github account to host the development,
 but the workflows and tooling do not align with 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Sean Dague
On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
 On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura kuk...@noironetworks.com
 mailto:kuk...@noironetworks.com wrote:
 
 On 8/4/14, 4:27 PM, Mark McClain wrote:
 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be
 should attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.
 The disconnect here is that the Neutron group-based policy sub-team
 that has been implementing this feature for Juno does not see this
 work as an experiment to gather data, but rather as an important
 innovative feature to put in the hands of early adopters in Juno and
 into widespread deployment with a stable API as early as Kilo. 
 
 
 The group-based policy BP approved for Juno addresses the critical
 need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely
 with all existing core plugins. Additionally, we believe that this
 declarative approach is what is needed to properly integrate
 advanced services into Neutron, and will go a long way towards
 resolving the difficulties so far trying to integrate LBaaS, FWaaS,
 and VPNaaS APIs into the current Neutron model.
 
 Like any new service API in Neutron, the initial group policy API
 release will be subject to incompatible changes before being
 declared stable, and hence would be labeled experimental in
 Juno. This does not mean that it is an experiment where to fail
 fast is an acceptable outcome. The sub-team's goal is to stabilize
 the group policy API as quickly as possible,  making any needed
 changes based on early user and operator experience.
 
 The L and M cycles that Mark suggests below to revisit the status
 are a completely different time frame. By the L or M cycle, we
 should be working on a new V3 Neutron API that pulls these APIs
 together into a more cohesive core API. We will not be in a position
 to do this properly without the experience of using the proposed
 group policy extension with the V2 Neutron API in production. 
 
 
 If we were failing miserably, or if serious technical issues were
 being identified with the patches, some delay might make sense. But,
 other than Mark's -2 blocking the initial patches from merging, we
 are on track to complete the planned work in Juno.
 
 -Bob
 
 
 
 As a member of nova-core, I find this whole discussion very startling.
 Putting aside the concerns over technical details and the pain of having
 in tree experimental APIs (such as nova v3 API), neutron still isn't the
 de-facto networking solution from nova's perspective and it won't be
 until neutron has feature and performance parity with nova-network. In
 fact due to the slow maturation of neutron, nova has moved nova-network
 from 'frozen' to open for development (with a few caveats).  So unless
 this new API directly solves some of the gaps in [0], I see no reason to
 push this into Juno. Juno hardly seems to be the appropriate time to
 introduce a new not-so-stable API; Juno is the time to address all the
 gaps [0] and hit feature and performance parity with nova-network.
 
 
 [0]
 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

I would agree.

There has been a pretty regular issue with Neutron team members working
on new features instead of getting Neutron to feature parity with Nova
network so we can retire the thing. This whole push for another API at
this stage makes no sense to me.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-04 Thread Hemanth Ravi
Hi,

I believe that the API has been reviewed well both for its usecases and
correctness. And the blueprint has been approved after sufficient exposure
of the API in the community. The best way to enable users to adopt GBP is
to introduce this in Juno rather than as a project in StackForge. Just as
in other APIs any evolutionary changes can be incorporated, going forward.

OS development processes are being followed in the implementation to make
sure that there is no negative impact on Neutron stability with the
inclusion of GBP.

Thanks,
-hemanth


On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain mmccl...@yahoo-inc.com wrote:

  All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.


 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy (GBP)
 for many months.  I think the discussion has reached a point where we need
 to openly discuss a few issues before moving forward.  I recognize that
 this discussion could create frustration for those who have invested
 significant time and energy, but the reality is we need ensure we are
 making decisions that benefit all members of our community (users,
 operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.  A
 good experiment should be designed to fail fast to enable further trials
 via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
  Releasing a new version of the proposed API every six months limits our
 ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.
  The results have been very mixed as operators either shy away from
 testing/offering the API or embrace the API with the expectation that the
 community will provide full API support and migration.  In both cases, the
 experiment fails because we either could not get the data we need or are
 unable to make significant changes without accepting a non-trivial amount
 of technical debt via migrations or draft API support.

 Next Steps
 --
 Previously, the GPB subteam used a Github account to host the development,
 but the workflows and tooling do not align with OpenStack's development
 model. I’d like to see us create a group based policy project in
 StackForge.  StackForge will host the code and enable us to follow the same
 open review and QA processes we use in the main project while we are
 developing and testing the API. The infrastructure there will benefit us as
 we will have a separate review velocity and can frequently publish
 libraries to PyPI.  From a technical perspective, the 13 new entities in
 GPB [1] do not require any changes to internal Neutron data structures.
  The docs[2] also suggest that an external plugin or service would work to
 make it easier to speed development.

 End State
 -
 APIs require time to fully bake and right now it is too early to know the
 final outcome.  Using StackForge will allow the team to retain all of its
 options including: merging the code into Neutron, adopting the repository
 as sub-project of the Network Program, leaving the project in StackForge
 project or learning that users want something completely different.  I
 would expect that we'll revisit the status of the repo during the L or M
 cycles since the Kilo development cycle does not leave enough time to
 experiment and iterate.


 mark

 [1]
 http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370
 [2]
 https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 [3]

 ___
 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] Group Based Policy and the way forward

2014-08-04 Thread Ivar Lazzaro
+1 Hemanth.


On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi hemanthrav...@gmail.com
wrote:

 Hi,

 I believe that the API has been reviewed well both for its usecases and
 correctness. And the blueprint has been approved after sufficient exposure
 of the API in the community. The best way to enable users to adopt GBP is
 to introduce this in Juno rather than as a project in StackForge. Just as
 in other APIs any evolutionary changes can be incorporated, going forward.

 OS development processes are being followed in the implementation to make
 sure that there is no negative impact on Neutron stability with the
 inclusion of GBP.

 Thanks,
 -hemanth


 On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain mmccl...@yahoo-inc.com
 wrote:

  All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.


 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy (GBP)
 for many months.  I think the discussion has reached a point where we need
 to openly discuss a few issues before moving forward.  I recognize that
 this discussion could create frustration for those who have invested
 significant time and energy, but the reality is we need ensure we are
 making decisions that benefit all members of our community (users,
 operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.  A
 good experiment should be designed to fail fast to enable further trials
 via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
  Releasing a new version of the proposed API every six months limits our
 ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental
 APIs.  The results have been very mixed as operators either shy away from
 testing/offering the API or embrace the API with the expectation that the
 community will provide full API support and migration.  In both cases, the
 experiment fails because we either could not get the data we need or are
 unable to make significant changes without accepting a non-trivial amount
 of technical debt via migrations or draft API support.

 Next Steps
 --
 Previously, the GPB subteam used a Github account to host the
 development, but the workflows and tooling do not align with OpenStack's
 development model. I’d like to see us create a group based policy project
 in StackForge.  StackForge will host the code and enable us to follow the
 same open review and QA processes we use in the main project while we are
 developing and testing the API. The infrastructure there will benefit us as
 we will have a separate review velocity and can frequently publish
 libraries to PyPI.  From a technical perspective, the 13 new entities in
 GPB [1] do not require any changes to internal Neutron data structures.
  The docs[2] also suggest that an external plugin or service would work to
 make it easier to speed development.

 End State
 -
 APIs require time to fully bake and right now it is too early to know the
 final outcome.  Using StackForge will allow the team to retain all of its
 options including: merging the code into Neutron, adopting the repository
 as sub-project of the Network Program, leaving the project in StackForge
 project or learning that users want something completely different.  I
 would expect that we'll revisit the status of the repo during the L or M
 cycles since the Kilo development cycle does not leave enough time to
 experiment and iterate.


 mark

 [1]
 http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370
 [2]
 https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 [3]

 ___
 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] Group Based Policy and the way forward

2014-08-04 Thread Armando M.
Hi,

When I think about Group-Based Policy I cannot help myself but think about
the degree of variety of sentiments (for lack of better words) that this
subject has raised over the past few months on the mailing list and/or
other venues.

I speak for myself when I say that when I look at the end-to-end
Group-Based Policy functionality I am not entirely sold on the following
points:

- The abstraction being proposed, its relationship with the Neutron API and
ODL;
- The way the reference implementation has been introduced into the
OpenStack world, and Neutron in particular;
- What an evolution of Group-Based Policy means going forward if we use the
proposed approach as a foundation for a more application-friendly and
intent-driven API abstraction going forward.
- The way we used development tools for bringing Neutron developers
(reviewers and committers), application developers, operators, and users
together around these new concepts.

Can I speak for everybody when I say that we do not have a consensus across
the board on all/some/other points being touched in this thread or other
threads? I think I can: I have witnessed that there is *NOT* such a
consensus. If I am asked where I stand, my position is that I wouldn't mind
to see how Group-Based Policy as we know it kick the tires; would I love to
see it do that in a way that's not disruptive to the Neutron project? YES,
I would love to.

So, where do we go from here? Do we need a consensus on such a delicate
area? I think we do.

I think Mark's intent, or anyone's who has at his/her heart the interest of
the Neutron community as a whole, is to make sure that we find a compromise
which everyone is comfortable with.

Do we vote about what we do next? Do we leave just cores to vote? I am not
sure. But one thing is certain, we cannot keep procrastinating as the Juno
window is about to expire.

I am sure that there are people hitching to get their hands on Group-Based
Policy, however the vehicle whereby this gets released should be irrelevant
to them; at the same time I appreciate that some people perceive Stackforge
projects as not as established and mature as other OpenStack projects; that
said wouldn't be fair to say that Group-Based Policy is exactly that? If
this means that other immature abstractions would need to follow suit, I
would be all in for this more decentralized approach. Can we do that now,
or do we postpone this discussion for the Kilo Summit? I don't know.

I realize that I have asked more questions than the answers I tried to
give, but I hope we can all engage in a constructive discussion.

Cheers,
Armando

PS: Salvatore I expressly stayed away from the GBP acronym you love so
much, so please read the thread and comment on it :)

On 4 August 2014 15:54, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 +1 Hemanth.


 On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi hemanthrav...@gmail.com
 wrote:

 Hi,

 I believe that the API has been reviewed well both for its usecases and
 correctness. And the blueprint has been approved after sufficient exposure
 of the API in the community. The best way to enable users to adopt GBP is
 to introduce this in Juno rather than as a project in StackForge. Just as
 in other APIs any evolutionary changes can be incorporated, going forward.

 OS development processes are being followed in the implementation to make
 sure that there is no negative impact on Neutron stability with the
 inclusion of GBP.

 Thanks,
 -hemanth


 On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain mmccl...@yahoo-inc.com
 wrote:

  All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.


 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy
 (GBP) for many months.  I think the discussion has reached a point where we
 need to openly discuss a few issues before moving forward.  I recognize
 that this discussion could create frustration for those who have invested
 significant time and energy, but the reality is we need ensure we are
 making decisions that benefit all members of our community (users,
 operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.  A
 good experiment should be designed to fail fast to enable further trials
 via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
  Releasing a new version of the proposed API every six months limits our
 ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental
 APIs.  The results have been very mixed as operators either shy 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-04 Thread loy wolfe
+1 mark


On Tue, Aug 5, 2014 at 4:27 AM, Mark McClain mmccl...@yahoo-inc.com wrote:

  All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be should
 attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.


 Why this email?
 ---
 Our community has been discussing and working on Group Based Policy (GBP)
 for many months.  I think the discussion has reached a point where we need
 to openly discuss a few issues before moving forward.  I recognize that
 this discussion could create frustration for those who have invested
 significant time and energy, but the reality is we need ensure we are
 making decisions that benefit all members of our community (users,
 operators, developers and vendors).

 Experimentation
 
 I like that as a community we are exploring alternate APIs.  The process
 of exploring via real user experimentation can produce valuable results.  A
 good experiment should be designed to fail fast to enable further trials
 via rapid iteration.

 Merging large changes into the master branch is the exact opposite of
 failing fast.

 The master branch deliberately favors small iterative changes over time.
  Releasing a new version of the proposed API every six months limits our
 ability to learn and make adjustments.

 In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.
  The results have been very mixed as operators either shy away from
 testing/offering the API or embrace the API with the expectation that the
 community will provide full API support and migration.  In both cases, the
 experiment fails because we either could not get the data we need or are
 unable to make significant changes without accepting a non-trivial amount
 of technical debt via migrations or draft API support.

 Next Steps
 --
 Previously, the GPB subteam used a Github account to host the development,
 but the workflows and tooling do not align with OpenStack's development
 model. I’d like to see us create a group based policy project in
 StackForge.  StackForge will host the code and enable us to follow the same
 open review and QA processes we use in the main project while we are
 developing and testing the API. The infrastructure there will benefit us as
 we will have a separate review velocity and can frequently publish
 libraries to PyPI.  From a technical perspective, the 13 new entities in
 GPB [1] do not require any changes to internal Neutron data structures.
  The docs[2] also suggest that an external plugin or service would work to
 make it easier to speed development.

 End State
 -
 APIs require time to fully bake and right now it is too early to know the
 final outcome.  Using StackForge will allow the team to retain all of its
 options including: merging the code into Neutron, adopting the repository
 as sub-project of the Network Program, leaving the project in StackForge
 project or learning that users want something completely different.  I
 would expect that we'll revisit the status of the repo during the L or M
 cycles since the Kilo development cycle does not leave enough time to
 experiment and iterate.


 mark

 [1]
 http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370
 [2]
 https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 [3]

 ___
 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