Re: [openstack-dev] [neutron] PTL candidacy for Rocky

[Morales, Victor]

+1, even if my vote doesn’t count.

From: Miguel Lavalle <mig...@mlavalle.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, February 5, 2018 at 11:21 AM
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron] PTL candidacy for Rocky

Hello OpenStack Community,
I write this to submit my candidacy for the Neutron PTL position during the 
Rocky cycle. I had the privilege of being the project's PTL for most of the 
Queens release series and want to have another opportunity helping the team and 
the community to deliver more and better networking  functionality.
I have worked for the technology industry 37+ years. After many years in 
management, I decided to return to the "Light Side of the Force", the technical 
path, and during the San Diego Summit in 2012 told the Neutron (Quantum at the 
time) PTL that one day I wanted to be a member of the core team. He and the 
team welcomed me and that started the best period of my career, not only for 
the never ending learning experiences, but more importantly, for the many 
talented women and men that I have met along the way. Over these past few years 
I worked for Rackspace, helping them to deploy and operate Neutron in their 
public cloud, IBM in their Linux Technology Center, and currently for Huawei, 
as their Neutron upstream development lead.
During the Queens release the team made significant progress in the following 
fronts:

  *   Continued with the adoption of Oslo Versioned Objects in the DB layer
  *   Implemented QoS rate limits for floating IPs
  *   Delivered the FWaaS V2.0 API
  *   Concluded the implementation of the logging API for security groups, 
which implements a way to capture and store events related to security groups.
  *   Continued moving externally referenced items to neutron-lib and adopting 
them in Neutron and the Stadium projects
  *   Welcomed VPNaaS back into the Stadium after the team put it back in shape
  *   Improved team processes such as having a pre-defined weekly schedule for 
team members to act as bug triagers, gave W+ to additional core members in 
neutron-lib and re-scheduled the Neutron drivers meeting on alternate days and 
hours to enable attendance of more people across different time zones

Some of the goals that I propose for the team to pursue during the Rocky cycle 
are:

  *   Finish the implementation of multiple port binding to solve the migration 
between VIF types in a generic way so operators can switch easily between 
backends. This is a joint effort with the Nova team
  *   Implement QoS minimum bandwidth allocation in the Placement API to 
support scheduling of instances based on the network bandwidth available in 
hosts. This is another joint effort with the Nova team
  *   Synchronize the adoption of the DB layer engine facade with the adoption 
of Oslo Versioned Objects to avoid situations where they don't cooperate nicely
  *   Implement port forwarding based on floating IPs
  *   Continue moving externally referenced items to neutron-lib and adopting 
them in Neutron and the Stadium projects. Finish documenting extensions in the 
API reference. Start the move of generic DB functionality to the library
  *   Expand the work done with the logging API in security groups to FWaaS v2.0
  *   Continue efforts in expanding our team and making its work easier. While 
we had some success during Queens, this is an area where we need to maintain 
our focus

Thank you for your consideration and for taking the time to read this

Miguel Lavalle (mlavalle)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL candidacy for Rocky

[Miguel Lavalle]

Hello OpenStack Community,

I write this to submit my candidacy for the Neutron PTL position during the
Rocky cycle. I had the privilege of being the project's PTL for most of the
Queens release series and want to have another opportunity helping the team
and the community to deliver more and better networking  functionality.

I have worked for the technology industry 37+ years. After many years in
management, I decided to return to the "Light Side of the Force", the
technical path, and during the San Diego Summit in 2012 told the Neutron
(Quantum at the time) PTL that one day I wanted to be a member of the core
team. He and the team welcomed me and that started the best period of my
career, not only for the never ending learning experiences, but more
importantly, for the many talented women and men that I have met along the
way. Over these past few years I worked for Rackspace, helping them to
deploy and operate Neutron in their public cloud, IBM in their Linux
Technology Center, and currently for Huawei, as their Neutron upstream
development lead.

During the Queens release the team made significant progress in the
following fronts:

   - Continued with the adoption of Oslo Versioned Objects in the DB layer
   - Implemented QoS rate limits for floating IPs
   - Delivered the FWaaS V2.0 API
   - Concluded the implementation of the logging API for security groups,
   which implements a way to capture and store events related to security
   groups.
   - Continued moving externally referenced items to neutron-lib and
   adopting them in Neutron and the Stadium projects
   - Welcomed VPNaaS back into the Stadium after the team put it back in
   shape
   - Improved team processes such as having a pre-defined weekly schedule
   for team members to act as bug triagers, gave W+ to additional core members
   in neutron-lib and re-scheduled the Neutron drivers meeting on alternate
   days and hours to enable attendance of more people across different time
   zones

Some of the goals that I propose for the team to pursue during the Rocky
cycle are:

   - Finish the implementation of multiple port binding to solve the
   migration between VIF types in a generic way so operators can switch easily
   between backends. This is a joint effort with the Nova team
   - Implement QoS minimum bandwidth allocation in the Placement API to
   support scheduling of instances based on the network bandwidth available in
   hosts. This is another joint effort with the Nova team
   - Synchronize the adoption of the DB layer engine facade with the
   adoption of Oslo Versioned Objects to avoid situations where they don't
   cooperate nicely
   - Implement port forwarding based on floating IPs
   - Continue moving externally referenced items to neutron-lib and
   adopting them in Neutron and the Stadium projects. Finish documenting
   extensions in the API reference. Start the move of generic DB functionality
   to the library
   - Expand the work done with the logging API in security groups to FWaaS
   v2.0
   - Continue efforts in expanding our team and making its work easier.
   While we had some success during Queens, this is an area where we need to
   maintain our focus

Thank you for your consideration and for taking the time to read this

Miguel Lavalle (mlavalle)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Kevin Benton]

>There is no such thing as arbitrary API. It is like one person's treasure
is other person's trash no body loves to create arbitrary APIs - there
are genuine needs.

Arbitrary in the sense that new APIs can be developed on-demand to solve
one specific use case that leads to fragmentation and incoherency of the
larger API.

>Some times we fail to understand requirements, other times the
requirements are not articulated clearly, which could lead to impressions
that arbitrary things are being added.

These are the reasons I don't want it to be so easy to define new APIs out
of tree. We can end up with 3 vendors trying to solve the same problem for
their customers and each will come up with a completely different
API/abstraction level that's tied to the vendor implementation.

If we have community discussions around adding new APIs in Neutron lib,
there is a documented review that has all of the requirements and use cases
articulated clearly.

>As newer workloads/technologies evolve, the need to orchestrate them
requires flexibility in the API.

I disagree, I think it means we need to add new Neutron APIs to orchestrate
them. Allowing each vendor to bypass the Neutron API entirely and come up
with their own API for orchestrating these workloads will just lead to
fragmentation.

>As I read/understand more about Gluon, that is being pushed by both
Operators/Users and Vendors.

I haven't seen many users pushing for a networking API that is different on
every cloud they use...

On Wed, Jan 25, 2017 at 10:06 AM, Sukhdev Kapur 
wrote:

> Folks, this is a great discussion. I hope this leads us to some good
> consensus and direction :-)
> I would suggest that we discuss this in upcoming PTG meeting as well.
>
>
> On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton  wrote:
>
>> >So I'm not sure that Kevin and Thierry's answers address Sukhdev's
>> point.
>>
>> I stated that I am happy to develop new APIs in Neutron. "So I'm all for
>> developing new APIs *as a community*"...
>>
>
> +1
>
>
>>
>> The important distinction I am making is that we can make new APIs (and
>> we do with routed networks as you mentioned, VLAN aware VMs, etc), but I
>> don't want to see the project just become a framework to make it even
>> easier than it is to define an arbitrary networking API.
>>
>
> There is no such thing as arbitrary API. It is like one person's treasure
> is other person's trash no body loves to create arbitrary APIs - there
> are genuine needs. Some times we fail to understand requirements, other
> times the requirements are not articulated clearly, which could lead to
> impressions that arbitrary things are being added.
>
>
>
>> >But I think that the point that Sukhdev raised - about other networking
>> projects being suggested because of Neutron being perceived as not flexible
>> enough
>>
>> I'm explicitly stating that if someone wants Neutron to become more
>> flexible to develop arbitrary APIs that diverge across deployments even
>> more, that's not something I'm going to support. However, making it
>> flexible for operators/users by adding new vendor-agnostic APIs is
>> something I will encourage.
>>
>
>> The reason I am stressing that distinction is because we have vendors
>> that want something like Gluon that allows them to define new arbitrary
>> APIs without upstreaming anything or working with the community to
>> standardize anything.
>>
> I understand that may be useful for some artisanal NFV workloads, but
>> that's not the direction I want to take Neutron.
>>
>
> OpenStack community consists of vendors and operators/users to facilitate
> and adoption of newer technologies as they evolve. As newer
> workloads/technologies evolve, the need to orchestrate them requires
> flexibility in the API. Labeling them as an arbitrary API  just because
> they do not fall into traditional L2/L3 networking model) is a harsh
> characterization.
>
>
>
>> Flexibility for operators/users = GOOD
>> Flexibility for vendor API injection = BAD
>>
>
> As I read/understand more about Gluon, that is being pushed by both
> Operators/Users and Vendors. I wonder which one is GOOD and which one is
> BAD :-):-)
>
> cheers..
> -Sukhdev
>
>
>
>
>>
>> On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram  wrote:
>>
>>> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez 
>>> wrote:
>>>
 Kevin Benton wrote:
 > [...]
 > The Neutron API is already very extensible and that's problematic.
 Right
 > now a vendor can write an out-of-tree service plugin or driver that
 adds
 > arbitrary fields and endpoints to the API that results in whatever
 > behavior they want. This is great for vendors because they can
 directly
 > expose features without having to make them vendor agnostic. However,
 > it's terrible for operators because it leads to lock-in and terrible
 for
 > the users because it leads to cross-cloud compatibility 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Kevin Benton]

I think we may also want to bring this up in a cross-project session at the
PTG. We are definitely to blame for some of the instability, but towards
the end of this cycle I have noticed lots of issues with HTTPS connection
errors, etc that don't seem to be related to Neutron at all. The squad team
will have to have members from other projects. :)

On Wed, Jan 25, 2017 at 10:29 AM, Ihar Hrachyshka 
wrote:

> On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor
>  wrote:
> > Given the latest issues related with the memory consumption[1] in CI
> jobs, I’m just wondering if you have a plan to deal and/or improve it in
> Neutron.
>
> AFAIU the root cause is still not clear, and we don't know if it's
> Neutron or job setup that triggers the OOM. I think we all see that
> the gate is not healthy lately (it's not just tempest, functional
> failure rate is also pretty bad). We need a squad team with clear
> ownership for failure tracking to get back to normal.
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Ian Wells]

On 25 January 2017 at 14:17, Monty Taylor  wrote:

> > Adding an additional networking project to try to solve this will only
> > make things work. We need one API. If it needs to grow features, it
> > needs to grow features - but they should be features that all of
> > OpenStack users get.
>
> WORSE - will make things WORSE - not work. Sorry for potentially
> completely misleading typo.
>

I should perhaps make clear that whenever I talk about 'other networking
APIs' I am not saying 'I think we should throw Neutron away' or 'we should
invent a shiny new API and compete with Neutron'.  I am saying that there's
value keeping the API of new features from intersecting the old when we add
things that are logically well separated from what we currently have.  As
it is, when you extend Neutron using current techniques, you have to touch
several elements of the existing API and you have no separation -
effectively you have to build outcroppings onto an API monolith.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Monty Taylor]

On 01/25/2017 08:16 AM, Monty Taylor wrote:
> On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
>>
>> Ihar and Kevin, 
>>
>> As our potential future PTLs, I would like to draw your attention to one
>> of the critical issue regarding Neutron as "the" networking service in
>> OpenStack. 
>>
>> I keep hearing off and on that Neutron is not flexible to address many
>> networking use cases and hence a new (or additional) networking project
>> is needed. For example, to address the use cases around NFV (rigid
>> resource inter-dependencies).  Another one keeps popping up is that it
>> is very hard/difficult to add/enhance Neutron API - hence, I picked this
>> one goal called out in Ihar's candidacy. 
> 
> Adding an additional networking project to try to solve this will only
> make things work. We need one API. If it needs to grow features, it
> needs to grow features - but they should be features that all of
> OpenStack users get.

WORSE - will make things WORSE - not work. Sorry for potentially
completely misleading typo.

>> I would really like us to discuss this issue head-on and see what is
>> missing in Neutron APIs and what would take to make them extensible so
>> that vendors do not run around trying to figure out alternative
>> solutions
> 
> +100
> 
>> cheers..
>> -Sukhdev
>>
>>
>>  
>>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>>
>>
>>
>>  
>>
>>
>> Thanks for attention,
>> Ihar
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton  wrote:

> >I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever behavior
> they want. This is great for vendors because they can directly expose
> features without having to make them vendor agnostic. However, it's
> terrible for operators because it leads to lock-in and terrible for the
> users because it leads to cross-cloud compatibility issues.
>
> For a concrete example of what I mean, take a look at this extension here:
> [1]. This is directly exposing vendor-specific things onto Neutron network
> API payloads. Nobody can build any tooling that depends on those fields
> without being locked into a specific vendor.
>

I do not believe this is a good example. I believe this is for monolithic
plugin (and probably pre-ML2 plugin time frame). If memory serves me right,
there were no specific guidelines at the time. I am sure there are many
other such examples relating to monolithic plugins.
However, I do get your point. Hence, the need to have a good look at the
API so that it can provide way for vendors and operators to expose the
strengths/features of their back-ends in a vendor agnostic fashion.

-Sukhdev



> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in place
> and it's not just a pass-through to a bunch of vendor-specific features. I
> would rather relax our constraint around requiring a reference
> implementation for new extensions in neutron-lib than continue to encourage
> developers to do expose whatever they want with the the existing extension
> framework.
>
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to encourage
> or make it easier for vendors to just build arbitrary extensions on top of
> Neutron that expose backend details.
>
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific networking
> APIs.
>
> 1. https://github.com/Juniper/contrail-neutron-plugin/blob/1
> 9ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contr
> ail/extensions/contrail.py#L9-L22
>
> Cheers,
> Kevin Benton
>
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur 
> wrote:
>
>>
>> Ihar and Kevin,
>>
>> As our potential future PTLs, I would like to draw your attention to one
>> of the critical issue regarding Neutron as "the" networking service in
>> OpenStack.
>>
>> I keep hearing off and on that Neutron is not flexible to address many
>> networking use cases and hence a new (or additional) networking project is
>> needed. For example, to address the use cases around NFV (rigid resource
>> inter-dependencies).  Another one keeps popping up is that it is very
>> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
>> called out in Ihar's candidacy.
>>
>> I would really like us to discuss this issue head-on and see what is
>> missing in Neutron APIs and what would take to make them extensible so that
>> vendors do not run around trying to figure out alternative solutions
>>
>> cheers..
>> -Sukhdev
>>
>>
>>
>>
>>> * Explore alternative ways to evolve Neutron API.  Piling up
>>> extensions and allowing third parties to completely change core
>>> resource behaviour is not ideal, and now that api-ref and API
>>> consolidation effort in neutron-lib are closer to completion, we may
>>> have better answers to outstanding questions than during previous
>>> attempts to crack the nut. I would like to restart the discussion some
>>> time during Pike.
>>>
>>
>>
>>
>>
>>>
>>> Thanks for attention,
>>> Ihar
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor
 wrote:
> Given the latest issues related with the memory consumption[1] in CI jobs, 
> I’m just wondering if you have a plan to deal and/or improve it in Neutron.

AFAIU the root cause is still not clear, and we don't know if it's
Neutron or job setup that triggers the OOM. I think we all see that
the gate is not healthy lately (it's not just tempest, functional
failure rate is also pretty bad). We need a squad team with clear
ownership for failure tracking to get back to normal.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

Folks,

This thread has gotten too long and hard to follow.
It is clear that we should discuss/address this.
My suggestion is that we organize a session in Atlanta PTG meeting and
discuss this.

I am going to add this on the Neutron etherpad - should this be included in
any other session as well?

-Sukhdev




On Tue, Jan 24, 2017 at 12:33 AM, Ihar Hrachyshka 
wrote:

> Hi team,
>
> I would like to propose my PTL candidacy for Pike.
>
> Some of you already know me. If not, here is my brief OpenStack bio. I
> joined the community back in Havana, and managed to stick around till
> now. During the time, I fit several project roles like serving as a
> Neutron liaison of different kinds (stable, oslo, release), fulfilling
> my Neutron core reviewer duties, taking part in delivering some
> longstanding features, leading QoS and upgrades subteams, as well as
> being part of Neutron Drivers team. I also took part in miscellaneous
> cross project efforts.
>
> I think my experience gives me broad perspective on how the OpenStack
> community and more specifically Networking works, and what is expected
> from its PTL.
>
> First, let me describe my vision of PTL role.
>
> * It's not only about technical intricacies. It's also about people
> and procedures that make the project run smoothly day by day. The role
> of PTL is in empowering other team members, keeping track of any
> roadblocks and inconveniences that the team have, and working on
> streamlining workflow.
>
> * It's about delegation. We should make it a habit to look at the list
> of potential candidates for core membership and other leadership and
> administrative positions not just in times we are short on existing
> members.
>
> * PTL should be transparent and replaceable. I will work with outgoing
> PTL to capture oral wisdom and state of affairs into a publicly
> accessible project dashboard, and I will continue sharing such
> information with the team on constant basis. The project dashboard
> will give you answers to questions like: what's the project direction?
> what are current priorities, and where does each stand?  what's on PTL
> and Drivers' mind? which cross-project and governance initiatives are
> currently worked on? etc.
>
> As PTL, I'd like to focus on the following things:
>
> * Speed up the RFE/spec process. We should manage RFE/spec review
> pipeline in such a way so that initiatives that are given a green
> light on writing up design details get timely feedback and can get
> past spec process in reasonable time.  At the same time we should be
> honest to the community not to accept proposals that have high risk to
> fall through cracks due to lack of manpower. I will encourage usage of
> reviewday and other tools to keep focus of the team. We will mull over
> the idea of virtual code sprints for high demand topics.
>
> * Continue Stadium program without drastic changes of direction.
> Thanks to Armando, we filled the Stadium with tangible meaning. I want
> us to build on top of that foundation to drive consistency and high
> quality standards between participating projects.
>
> * Support Marketplace rework. With huge number of drivers and plugins
> available for Neutron, it became hard for operators to pick the right
> one and for vendors to advertise their features. There is strong
> vendor interest to improve situation there. We should boost Feature
> Classification work, and integrate it with how third party CI systems
> report test results so that they become useful for Marketplace.
>
> * Introduce Gate Keeper role. We've recently made significant progress
> in how we deal with gate: we expanded coverage to new types of jobs,
> we utilize Grafana and other community tools, we review gate-failure
> tagged bugs during weekly meetings. Sadly, sometimes gate becomes
> unstable, and it slows down work progress for everyone.  In such
> cases, it's all about timely addressing the issue. For that matter, I
> will work with the team on defining a new Gate Keeper role that would
> help prioritizing current gate issues, as well as proactively work
> with the team on gate instability vectors. I believe clear ownership
> is the key.
>
> * Make centralized L3 legacy indeed. We have DVR and HA in tree for
> quite some time. Both technologies are now mature enough, and are no
> longer mutually exclusive. Sadly, they are still second class citizens
> in our own gate.  My belief is we should give users a clear signal
> that old L3 is indeed legacy by switching our jobs to DVR+HA where
> applicable.  I am sure that will surface some previously unknown
> issues, but we'll be ready to tackle them.  While it's never black or
> white, I suggest we prioritize this work over adding new major L3
> features.
>
> * Support existing maintenance initiatives. I'd like us to close
> neutron-lib saga in Pike, and consider neutron-lib switch for a
> requirement to all Stadium projects starting from Queens. We should
> also close OSC transition 

Re: [openstack-dev] [neutron] PTL candidacy

[Ihar Hrachyshka]

On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton  wrote:
> LBaaS is a little special since Octavia will have it's own API endpoint
> completely that they will evolve on their own. The other spun-out projects
> (e.g. VPNaaS) will have the API defined in neutron-lib[1].

In a way, VPNaaS is also special, because it's an out-of-stadium repo
that nevertheless brings its own full blown API definition. We will
need to sort that out.

I see that you suggest we should work on bringing VPNaaS back into the
stadium during Pike. While I am not confidant that it may happen in a
single cycle (there were plenty of issues with the repo identified
during latest stadium assessment), I agree that, assuming we want that
API to exist in the future, it makes sense to bring it back in.
Especially if in the future we want to programmatically enforce single
source of API truth.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

Folks, this is a great discussion. I hope this leads us to some good
consensus and direction :-)
I would suggest that we discuss this in upcoming PTG meeting as well.


On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton  wrote:

> >So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.
>
> I stated that I am happy to develop new APIs in Neutron. "So I'm all for
> developing new APIs *as a community*"...
>

+1


>
> The important distinction I am making is that we can make new APIs (and we
> do with routed networks as you mentioned, VLAN aware VMs, etc), but I don't
> want to see the project just become a framework to make it even easier than
> it is to define an arbitrary networking API.
>

There is no such thing as arbitrary API. It is like one person's treasure
is other person's trash no body loves to create arbitrary APIs - there
are genuine needs. Some times we fail to understand requirements, other
times the requirements are not articulated clearly, which could lead to
impressions that arbitrary things are being added.



> >But I think that the point that Sukhdev raised - about other networking
> projects being suggested because of Neutron being perceived as not flexible
> enough
>
> I'm explicitly stating that if someone wants Neutron to become more
> flexible to develop arbitrary APIs that diverge across deployments even
> more, that's not something I'm going to support. However, making it
> flexible for operators/users by adding new vendor-agnostic APIs is
> something I will encourage.
>

> The reason I am stressing that distinction is because we have vendors that
> want something like Gluon that allows them to define new arbitrary APIs
> without upstreaming anything or working with the community to standardize
> anything.
>
I understand that may be useful for some artisanal NFV workloads, but
> that's not the direction I want to take Neutron.
>

OpenStack community consists of vendors and operators/users to facilitate
and adoption of newer technologies as they evolve. As newer
workloads/technologies evolve, the need to orchestrate them requires
flexibility in the API. Labeling them as an arbitrary API  just because
they do not fall into traditional L2/L3 networking model) is a harsh
characterization.



> Flexibility for operators/users = GOOD
> Flexibility for vendor API injection = BAD
>

As I read/understand more about Gluon, that is being pushed by both
Operators/Users and Vendors. I wonder which one is GOOD and which one is
BAD :-):-)

cheers..
-Sukhdev




>
> On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram  wrote:
>
>> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez 
>> wrote:
>>
>>> Kevin Benton wrote:
>>> > [...]
>>> > The Neutron API is already very extensible and that's problematic.
>>> Right
>>> > now a vendor can write an out-of-tree service plugin or driver that
>>> adds
>>> > arbitrary fields and endpoints to the API that results in whatever
>>> > behavior they want. This is great for vendors because they can directly
>>> > expose features without having to make them vendor agnostic. However,
>>> > it's terrible for operators because it leads to lock-in and terrible
>>> for
>>> > the users because it leads to cross-cloud compatibility issues.
>>>
>>> +1000 on this being a major problem in Neutron. Happy to see that you
>>> want to work on trying to reduce it.
>>
>>
>> The Neutron API is a model of what forms of connectivity can be
>> expressed, between instances and the outside world.  Once that model is
>> chosen, it is inevitably (and simultaneously):
>>
>> (a) overconstraining - in other words, there will be forms of
>> connectivity that someone could reasonably want, but that are not allowed
>> by the model
>>
>> (b) underconstraining - in other words, there will be nuances of
>> behaviour, delivered by a particular implementation, that are arguably
>> within what the model allows, but (as we're talking about semantics) it
>> would really be better to revise the API so that it can explicitly express
>> those nuances.
>>
>> Sometimes - since the semantics of the Neutron API are not precisely
>> documented - it's not clear which of these situations one is in.  But I
>> think that the point that Sukhdev raised - about other networking projects
>> being suggested because of Neutron being perceived as not flexible enough -
>> is to do with (a); whereas the points that Kevin and Thierry responded with
>> - ways that the API is already _too_ flexible - are to do with (b).  So I'm
>> not sure that Kevin and Thierry's answers address Sukhdev's point.
>>
>> It's possible for an API to have (a) and (b) problems simultaneously, and
>> to make progress on addressing them both.  In Neutron's case, a major
>> example of (a) has been the routed networks work, which (among other
>> things) generalized Neutron's network concept from being something that
>> always provides L2 adjacency between its ports, to something that 

Re: [openstack-dev] [neutron] PTL candidacy

[Ihar Hrachyshka]

Catching up on the thread, lots of good thoughts.

I don't think there is disagreement here around how Networking API
should evolve in terms of vendor extensions. As Kevin suggested, we
don't want to advertise API extensibility without Neutron team
supervision.

One of the reasons behind current api-ref effort that includes moving
API definitions from all stadium projects into neutron-lib - and
vouching for new API changes in scope of this single repo - is to
transform Neutron from a shallow API controller that allows to plug in
opaque API modules into a single API with consistent behavior, review
practices and standards.

I would go as far as to say that once that effort is complete, we
should start looking for ways to discourage (if not forbid) API
pluggability not proxied through proper in-neutron-lib review process.
It's one thing to allow plugging in different networking backends that
all implement the same Networking API behavior; and it's completely
different to allow those plugins to change Networking API to the point
where you can't even tell if it's open API guaranteed to work in other
environments.

Yes, there is concern that Networking API doesn't move as quick as
some vendors may want. We can address that with streamlining review
process for new API definitions. As long as an API proposal makes
sense not just for one specific backend, and is defined in general
enough terms, I think we can go with expedited review procedure.
Indeed we should probably reconsider how we enforce reference
implementation completion before an extension is allowed in.

Ihar

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  wrote:
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one of
> the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is missing
> in Neutron APIs and what would take to make them extensible so that vendors
> do not run around trying to figure out alternative solutions
>
> cheers..
> -Sukhdev
>
>
>
>>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>
>
>
>
>>
>>
>> Thanks for attention,
>> Ihar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Kevin Benton]

LBaaS is a little special since Octavia will have it's own API endpoint
completely that they will evolve on their own. The other spun-out projects
(e.g. VPNaaS) will have the API defined in neutron-lib[1].

The specific DVR issue you are referring to with roaming IPs being the
target of floating IPs (I think that's what you're referring to) is
something I'm planning to address in Pike with the help of other DVR
contributors because floating IP translations for unbound addresses blocks
various other use cases.

1.
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/vpnaas.inc

On Wed, Jan 25, 2017 at 6:40 AM, Hayes, Graham  wrote:

> On 25/01/2017 01:08, Kevin Benton wrote:
> >>I would really like us to discuss this issue head-on and see what is
> > missing in Neutron APIs and what would take to make them extensible so
> > that vendors do not run around trying to figure out alternative
> > solutions
> >
> > The Neutron API is already very extensible and that's problematic. Right
> > now a vendor can write an out-of-tree service plugin or driver that adds
> > arbitrary fields and endpoints to the API that results in whatever
> > behavior they want. This is great for vendors because they can directly
> > expose features without having to make them vendor agnostic. However,
> > it's terrible for operators because it leads to lock-in and terrible for
> > the users because it leads to cross-cloud compatibility issues.
> >
> > For a concrete example of what I mean, take a look at this extension
> > here: [1]. This is directly exposing vendor-specific things onto Neutron
> > network API payloads. Nobody can build any tooling that depends on those
> > fields without being locked into a specific vendor.
> >
> > So what I would like to encourage is bringing API extension work into
> > Neutron-lib where we can ensure that the relevant abstractions are in
> > place and it's not just a pass-through to a bunch of vendor-specific
> > features. I would rather relax our constraint around requiring a
> > reference implementation for new extensions in neutron-lib than continue
> > to encourage developers to do expose whatever they want with the the
> > existing extension framework.
> >
> > So I'm all for developing new APIs *as a community* to enable NFV use
> > cases not supported by the current APIs. However, I don't want to
> > encourage or make it easier for vendors to just build arbitrary
> > extensions on top of Neutron that expose backend details.
> >
> > In my view, Neutron should provide a unified API for networking across
> > OpenStack clouds, not a platform for writing deployment-specific
> > networking APIs.
>
> How does this tie in with the removal of some of the networking *aaS
> projects from the stadium? I know LBaaS is doing a shim API layer in
> the short term, but long term that will have to move to a separate API.
>
> How do you think this will impact inter service bugs (e.g. Octavia HA +
> Neutron DVR issues that have been around for cycles)
>
> >
> > 1. https://github.com/Juniper/contrail-neutron-plugin/blob/
> 19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_
> contrail/extensions/contrail.py#L9-L22
> >
> > Cheers,
> > Kevin Benton
> >
> > On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  > > wrote:
> >
> >
> > Ihar and Kevin,
> >
> > As our potential future PTLs, I would like to draw your attention to
> > one of the critical issue regarding Neutron as "the" networking
> > service in OpenStack.
> >
> > I keep hearing off and on that Neutron is not flexible to address
> > many networking use cases and hence a new (or additional) networking
> > project is needed. For example, to address the use cases around NFV
> > (rigid resource inter-dependencies).  Another one keeps popping up
> > is that it is very hard/difficult to add/enhance Neutron API -
> > hence, I picked this one goal called out in Ihar's candidacy.
> >
> > I would really like us to discuss this issue head-on and see what is
> > missing in Neutron APIs and what would take to make them extensible
> > so that vendors do not run around trying to figure out alternative
> > solutions
> >
> > cheers..
> > -Sukhdev
> >
> >
> >
> >
> > * Explore alternative ways to evolve Neutron API.  Piling up
> > extensions and allowing third parties to completely change core
> > resource behaviour is not ideal, and now that api-ref and API
> > consolidation effort in neutron-lib are closer to completion, we
> may
> > have better answers to outstanding questions than during previous
> > attempts to crack the nut. I would like to restart the
> > discussion some
> > time during Pike.
> >
> >
> >
> >
> >
> >
> > Thanks for attention,
> > Ihar
> >
> > 

Re: [openstack-dev] [neutron] PTL candidacy

[Hayes, Graham]

On 25/01/2017 01:08, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever
> behavior they want. This is great for vendors because they can directly
> expose features without having to make them vendor agnostic. However,
> it's terrible for operators because it leads to lock-in and terrible for
> the users because it leads to cross-cloud compatibility issues.
>
> For a concrete example of what I mean, take a look at this extension
> here: [1]. This is directly exposing vendor-specific things onto Neutron
> network API payloads. Nobody can build any tooling that depends on those
> fields without being locked into a specific vendor.
>
> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in
> place and it's not just a pass-through to a bunch of vendor-specific
> features. I would rather relax our constraint around requiring a
> reference implementation for new extensions in neutron-lib than continue
> to encourage developers to do expose whatever they want with the the
> existing extension framework.
>
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to
> encourage or make it easier for vendors to just build arbitrary
> extensions on top of Neutron that expose backend details.
>
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific
> networking APIs.

How does this tie in with the removal of some of the networking *aaS
projects from the stadium? I know LBaaS is doing a shim API layer in
the short term, but long term that will have to move to a separate API.

How do you think this will impact inter service bugs (e.g. Octavia HA +
Neutron DVR issues that have been around for cycles)

>
> 1. 
> https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22
>
> Cheers,
> Kevin Benton
>
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  > wrote:
>
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to
> one of the critical issue regarding Neutron as "the" networking
> service in OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address
> many networking use cases and hence a new (or additional) networking
> project is needed. For example, to address the use cases around NFV
> (rigid resource inter-dependencies).  Another one keeps popping up
> is that it is very hard/difficult to add/enhance Neutron API -
> hence, I picked this one goal called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible
> so that vendors do not run around trying to figure out alternative
> solutions
>
> cheers..
> -Sukhdev
>
>
>
>
> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the
> discussion some
> time during Pike.
>
>
>
>
>
>
> Thanks for attention,
> Ihar
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Re: [openstack-dev] [neutron] PTL candidacy

[Monty Taylor]

On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
> 
> Ihar and Kevin, 
> 
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack. 
> 
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project
> is needed. For example, to address the use cases around NFV (rigid
> resource inter-dependencies).  Another one keeps popping up is that it
> is very hard/difficult to add/enhance Neutron API - hence, I picked this
> one goal called out in Ihar's candidacy. 

Adding an additional networking project to try to solve this will only
make things work. We need one API. If it needs to grow features, it
needs to grow features - but they should be features that all of
OpenStack users get.

> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions

+100

> cheers..
> -Sukhdev
> 
> 
>  
> 
> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the discussion some
> time during Pike.
> 
> 
> 
>  
> 
> 
> Thanks for attention,
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Monty Taylor]

On 01/24/2017 08:04 PM, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
> 
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever
> behavior they want. This is great for vendors because they can directly
> expose features without having to make them vendor agnostic. However,
> it's terrible for operators because it leads to lock-in and terrible for
> the users because it leads to cross-cloud compatibility issues. 
> 
> For a concrete example of what I mean, take a look at this extension
> here: [1]. This is directly exposing vendor-specific things onto Neutron
> network API payloads. Nobody can build any tooling that depends on those
> fields without being locked into a specific vendor.
> 
> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in
> place and it's not just a pass-through to a bunch of vendor-specific
> features. I would rather relax our constraint around requiring a
> reference implementation for new extensions in neutron-lib than continue
> to encourage developers to do expose whatever they want with the the
> existing extension framework.
> 
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to
> encourage or make it easier for vendors to just build arbitrary
> extensions on top of Neutron that expose backend details.
> 
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific
> networking APIs.

A billion times yes.



> 1. 
> https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22
> 
> Cheers,
> Kevin Benton
> 
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  > wrote:
> 
> 
> Ihar and Kevin, 
> 
> As our potential future PTLs, I would like to draw your attention to
> one of the critical issue regarding Neutron as "the" networking
> service in OpenStack. 
> 
> I keep hearing off and on that Neutron is not flexible to address
> many networking use cases and hence a new (or additional) networking
> project is needed. For example, to address the use cases around NFV
> (rigid resource inter-dependencies).  Another one keeps popping up
> is that it is very hard/difficult to add/enhance Neutron API -
> hence, I picked this one goal called out in Ihar's candidacy. 
> 
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible
> so that vendors do not run around trying to figure out alternative
> solutions
> 
> cheers..
> -Sukhdev
> 
> 
>  
> 
> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the
> discussion some
> time during Pike.
> 
> 
> 
>  
> 
> 
> Thanks for attention,
> Ihar
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [neutron] PTL candidacy

[Kevin Benton]

>So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.

I stated that I am happy to develop new APIs in Neutron. "So I'm all for
developing new APIs *as a community*"...

The important distinction I am making is that we can make new APIs (and we
do with routed networks as you mentioned, VLAN aware VMs, etc), but I don't
want to see the project just become a framework to make it even easier than
it is to define an arbitrary networking API.

>But I think that the point that Sukhdev raised - about other networking
projects being suggested because of Neutron being perceived as not flexible
enough

I'm explicitly stating that if someone wants Neutron to become more
flexible to develop arbitrary APIs that diverge across deployments even
more, that's not something I'm going to support. However, making it
flexible for operators/users by adding new vendor-agnostic APIs is
something I will encourage.

The reason I am stressing that distinction is because we have vendors that
want something like Gluon that allows them to define new arbitrary APIs
without upstreaming anything or working with the community to standardize
anything. I understand that may be useful for some artisanal NFV workloads,
but that's not the direction I want to take Neutron.

Flexibility for operators/users = GOOD
Flexibility for vendor API injection = BAD

On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram  wrote:

> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez 
> wrote:
>
>> Kevin Benton wrote:
>> > [...]
>> > The Neutron API is already very extensible and that's problematic. Right
>> > now a vendor can write an out-of-tree service plugin or driver that adds
>> > arbitrary fields and endpoints to the API that results in whatever
>> > behavior they want. This is great for vendors because they can directly
>> > expose features without having to make them vendor agnostic. However,
>> > it's terrible for operators because it leads to lock-in and terrible for
>> > the users because it leads to cross-cloud compatibility issues.
>>
>> +1000 on this being a major problem in Neutron. Happy to see that you
>> want to work on trying to reduce it.
>
>
> The Neutron API is a model of what forms of connectivity can be expressed,
> between instances and the outside world.  Once that model is chosen, it is
> inevitably (and simultaneously):
>
> (a) overconstraining - in other words, there will be forms of connectivity
> that someone could reasonably want, but that are not allowed by the model
>
> (b) underconstraining - in other words, there will be nuances of
> behaviour, delivered by a particular implementation, that are arguably
> within what the model allows, but (as we're talking about semantics) it
> would really be better to revise the API so that it can explicitly express
> those nuances.
>
> Sometimes - since the semantics of the Neutron API are not precisely
> documented - it's not clear which of these situations one is in.  But I
> think that the point that Sukhdev raised - about other networking projects
> being suggested because of Neutron being perceived as not flexible enough -
> is to do with (a); whereas the points that Kevin and Thierry responded with
> - ways that the API is already _too_ flexible - are to do with (b).  So I'm
> not sure that Kevin and Thierry's answers address Sukhdev's point.
>
> It's possible for an API to have (a) and (b) problems simultaneously, and
> to make progress on addressing them both.  In Neutron's case, a major
> example of (a) has been the routed networks work, which (among other
> things) generalized Neutron's network concept from being something that
> always provides L2 adjacency between its ports, to something that may or
> may not.  So it seems to me that Neutron is able to address (a) problems.
>  (I'm personally less familiar with (b), but would guess that progress is
> being made there too.)
>
> Regards,
>  Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Neil Jerram]

On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez 
wrote:

> Kevin Benton wrote:
> > [...]
> > The Neutron API is already very extensible and that's problematic. Right
> > now a vendor can write an out-of-tree service plugin or driver that adds
> > arbitrary fields and endpoints to the API that results in whatever
> > behavior they want. This is great for vendors because they can directly
> > expose features without having to make them vendor agnostic. However,
> > it's terrible for operators because it leads to lock-in and terrible for
> > the users because it leads to cross-cloud compatibility issues.
>
> +1000 on this being a major problem in Neutron. Happy to see that you
> want to work on trying to reduce it.


The Neutron API is a model of what forms of connectivity can be expressed,
between instances and the outside world.  Once that model is chosen, it is
inevitably (and simultaneously):

(a) overconstraining - in other words, there will be forms of connectivity
that someone could reasonably want, but that are not allowed by the model

(b) underconstraining - in other words, there will be nuances of behaviour,
delivered by a particular implementation, that are arguably within what the
model allows, but (as we're talking about semantics) it would really be
better to revise the API so that it can explicitly express those nuances.

Sometimes - since the semantics of the Neutron API are not precisely
documented - it's not clear which of these situations one is in.  But I
think that the point that Sukhdev raised - about other networking projects
being suggested because of Neutron being perceived as not flexible enough -
is to do with (a); whereas the points that Kevin and Thierry responded with
- ways that the API is already _too_ flexible - are to do with (b).  So I'm
not sure that Kevin and Thierry's answers address Sukhdev's point.

It's possible for an API to have (a) and (b) problems simultaneously, and
to make progress on addressing them both.  In Neutron's case, a major
example of (a) has been the routed networks work, which (among other
things) generalized Neutron's network concept from being something that
always provides L2 adjacency between its ports, to something that may or
may not.  So it seems to me that Neutron is able to address (a) problems.
 (I'm personally less familiar with (b), but would guess that progress is
being made there too.)

Regards,
 Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Thierry Carrez]

Kevin Benton wrote:
> [...]
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever
> behavior they want. This is great for vendors because they can directly
> expose features without having to make them vendor agnostic. However,
> it's terrible for operators because it leads to lock-in and terrible for
> the users because it leads to cross-cloud compatibility issues. 

+1000 on this being a major problem in Neutron. Happy to see that you
want to work on trying to reduce it.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Kevin Benton]

>I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions

The Neutron API is already very extensible and that's problematic. Right
now a vendor can write an out-of-tree service plugin or driver that adds
arbitrary fields and endpoints to the API that results in whatever behavior
they want. This is great for vendors because they can directly expose
features without having to make them vendor agnostic. However, it's
terrible for operators because it leads to lock-in and terrible for the
users because it leads to cross-cloud compatibility issues.

For a concrete example of what I mean, take a look at this extension here:
[1]. This is directly exposing vendor-specific things onto Neutron network
API payloads. Nobody can build any tooling that depends on those fields
without being locked into a specific vendor.

So what I would like to encourage is bringing API extension work into
Neutron-lib where we can ensure that the relevant abstractions are in place
and it's not just a pass-through to a bunch of vendor-specific features. I
would rather relax our constraint around requiring a reference
implementation for new extensions in neutron-lib than continue to encourage
developers to do expose whatever they want with the the existing extension
framework.

So I'm all for developing new APIs *as a community* to enable NFV use cases
not supported by the current APIs. However, I don't want to encourage or
make it easier for vendors to just build arbitrary extensions on top of
Neutron that expose backend details.

In my view, Neutron should provide a unified API for networking across
OpenStack clouds, not a platform for writing deployment-specific networking
APIs.

1.
https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22

Cheers,
Kevin Benton

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur 
wrote:

>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> cheers..
> -Sukhdev
>
>
>
>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>>
>
>
>
>
>>
>> Thanks for attention,
>> Ihar
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Jay Pipes]

On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:

Ihar and Kevin,

As our potential future PTLs, I would like to draw your attention to one
of the critical issue regarding Neutron as "the" networking service in
OpenStack.

I keep hearing off and on that Neutron is not flexible to address many
networking use cases and hence a new (or additional) networking project
is needed. For example, to address the use cases around NFV (rigid
resource inter-dependencies).  Another one keeps popping up is that it
is very hard/difficult to add/enhance Neutron API - hence, I picked this
one goal called out in Ihar's candidacy.

I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so
that vendors do not run around trying to figure out alternative
solutions


Big +1 from me on the above. Please work with the API working group, too!

Best,
-jay


* Explore alternative ways to evolve Neutron API.  Piling up
extensions and allowing third parties to completely change core
resource behaviour is not ideal, and now that api-ref and API
consolidation effort in neutron-lib are closer to completion, we may
have better answers to outstanding questions than during previous
attempts to crack the nut. I would like to restart the discussion some
time during Pike.






Thanks for attention,
Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Sukhdev Kapur]

On Tue, Jan 24, 2017 at 3:24 PM, Edgar Magana <edgar.mag...@workday.com>
wrote:

> You just made me remember my time as police man for Neutron plugins!  ☺
>

Now we can have distributed police men :-)

-Sukhdev



>
>
> Edgar
>
>
>
> *From: *Sukhdev Kapur <sukhdevka...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Tuesday, January 24, 2017 at 3:14 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Neutron] PTL Candidacy
>
>
>
> I remember good old days when CI was introduced in Neutron (during
> Icehouse time frame). There was excellent momentum behind it. We did not
> know some of the enforcement details, which created lots of
> confusion/havoc.
>
>
>
> Now that we have a better understanding of the past issues, and lots of
> good ideas to address them, I think it is appropriate to reactivate the
> process.
>
> As to Jeremy's options, I think option B makes the best sense - the driver
> author/owner should bare the burden of declaring a driver/plugin compatible.
>
>
>
> cheers..
>
> -Sukhdev
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley <fu...@yuggoth.org>
> wrote:
>
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> Jeremy Stanley
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc=J3l_htX2j4f1reTu2w6i8YUD4Q_0YgpguIiCHlJB0PE=>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.op

Re: [openstack-dev] [Neutron] PTL Candidacy

[Sukhdev Kapur]

I remember good old days when CI was introduced in Neutron (during Icehouse
time frame). There was excellent momentum behind it. We did not know some
of the enforcement details, which created lots of confusion/havoc.

Now that we have a better understanding of the past issues, and lots of
good ideas to address them, I think it is appropriate to reactivate the
process.
As to Jeremy's options, I think option B makes the best sense - the driver
author/owner should bare the burden of declaring a driver/plugin compatible.

cheers..
-Sukhdev


On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

Ihar and Kevin,

As our potential future PTLs, I would like to draw your attention to one of
the critical issue regarding Neutron as "the" networking service in
OpenStack.

I keep hearing off and on that Neutron is not flexible to address many
networking use cases and hence a new (or additional) networking project is
needed. For example, to address the use cases around NFV (rigid resource
inter-dependencies).  Another one keeps popping up is that it is very
hard/difficult to add/enhance Neutron API - hence, I picked this one goal
called out in Ihar's candidacy.

I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions

cheers..
-Sukhdev




> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the discussion some
> time during Pike.
>




>
> Thanks for attention,
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Edgar Magana]

You just made me remember my time as police man for Neutron plugins!  ☺

Edgar

From: Sukhdev Kapur <sukhdevka...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, January 24, 2017 at 3:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] PTL Candidacy

I remember good old days when CI was introduced in Neutron (during Icehouse 
time frame). There was excellent momentum behind it. We did not know some of 
the enforcement details, which created lots of confusion/havoc.

Now that we have a better understanding of the past issues, and lots of good 
ideas to address them, I think it is appropriate to reactivate the process.
As to Jeremy's options, I think option B makes the best sense - the driver 
author/owner should bare the burden of declaring a driver/plugin compatible.

cheers..
-Sukhdev


On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley 
<fu...@yuggoth.org<mailto:fu...@yuggoth.org>> wrote:
On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote:
> > I'm on board with getting visibility into the drivers with improvements to
> > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > 'validation'. Core reviewers don't frequently have access to the hardware or
> > software required to validate these drivers so we can't be sure if the
> > features really are working as expected.
> >
> > If validation is as flexible as you highlighted in the email, we can at
> > least get it to a point where all recent CI runs are linkable from driverlog
> > and people can see recent tempest runs. I don't foresee the Neutron team
> > getting to a point soon where we vouch for certain drivers though just
> > because it is so hard to keep up with their changes (even ignoring changes
> > in the vendor hardware itself).
>
> Good point. We may guide plugins and drivers on how to set up CI; we
> may help Foundation to set up Marketplace in such a way that would
> allow to automatically consume test artifacts from driver owners; we
> may provide guidance to Foundation about which features are more
> important to reflect that in Marketplace; but I would hope we don't
> put the Neutron team on the hook to validate each driver, or even
> police CI owners to produce consumable results. (The stick in the
> latter case would be driver not showing up in Marketplace, or showing
> up with no feature support information.)

I guess the question I have is who, then, can tell our
operators/users what Neutron drivers are reasonably supported? It
sounds like you're saying Neutron developers are not well-placed to
determine that, which leaves us with these other options:

A. Have the OpenStack Foundation as maintainers of the Marketplace
   decide which Neutron drivers are usable (they don't really staff
   for this purpose so would be throwing darts I think)

B. Trust the driver authors to declare whether they're supported and
   what features they provide (maybe that works better than I
   expect?)

C. Identify another party with a vested interest in validating
   driver support (a board of operators from different organizations
   maybe?)

D. Provide links/aggregation of QA/CI and let the consumers attempt
   to divine supportability for themselves (seems a bit downstream
   hostile)

Are any of those options preferable?
--
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc=J3l_htX2j4f1reTu2w6i8YUD4Q_0YgpguIiCHlJB0PE=>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwMFaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc=j5yF8PsqCjQ64dZ3etZCnJfe9H7rlO9gO1xHDXbUf50=>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Candidacy

[Sukhdev Kapur]

In deed, excellent and well qualified candidates.

Best of Luck to both

-Sukhdev


On Tue, Jan 24, 2017 at 7:16 AM, Armando M.  wrote:

> Hi neutrinos,
>
> No, it's not what you might be thinking...I am just delighted to see two
> excellent candidates willing to take the reins of the project going forward
> [1,2].
>
> I couldn't hope for more enthusiasm; best of luck to both candidates and
> anyone else who is going to step up! This is exciting!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/423552/
> [2] https://review.openstack.org/#/c/424500/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Jeremy Stanley]

On 2017-01-24 13:10:26 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:
[...]
> > I guess the question I have is who, then, can tell our
> > operators/users what Neutron drivers are reasonably supported? It
> > sounds like you're saying Neutron developers are not well-placed to
> > determine that, which leaves us with these other options:
> >
> > A. Have the OpenStack Foundation as maintainers of the Marketplace
> >decide which Neutron drivers are usable (they don't really staff
> >for this purpose so would be throwing darts I think)
> >
> > B. Trust the driver authors to declare whether they're supported and
> >what features they provide (maybe that works better than I
> >expect?)
> >
> > C. Identify another party with a vested interest in validating
> >driver support (a board of operators from different organizations
> >maybe?)
> >
> > D. Provide links/aggregation of QA/CI and let the consumers attempt
> >to divine supportability for themselves (seems a bit downstream
> >hostile)
> >
> > Are any of those options preferable?
> 
> I think it's B, but under Neutron team supervision. As a first step,
> we would need to come up with an objective way to compare existing
> drivers, and anarchy in how they execute tests, set up environment,
> and publish artifacts won't make it easy.
[...]

Thanks, that's reassuring. I took your previous statements to
indicate a much more hands-off approach than your reply suggests.
This does seem at least compatible with the mix of in-tree and
out-of-tree driver tracking and feature matrices being done or
planned by the teams responsible for other services, so I have hopes
we can ultimately come up with a converged model that's not too
onerous to aggregate in the Driver Marketplace.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
>> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
>> > I'm on board with getting visibility into the drivers with improvements to
>> > driverlog, etc. What I'm uncertain of is providing much in the lines of
>> > 'validation'. Core reviewers don't frequently have access to the hardware 
>> > or
>> > software required to validate these drivers so we can't be sure if the
>> > features really are working as expected.
>> >
>> > If validation is as flexible as you highlighted in the email, we can at
>> > least get it to a point where all recent CI runs are linkable from 
>> > driverlog
>> > and people can see recent tempest runs. I don't foresee the Neutron team
>> > getting to a point soon where we vouch for certain drivers though just
>> > because it is so hard to keep up with their changes (even ignoring changes
>> > in the vendor hardware itself).
>>
>> Good point. We may guide plugins and drivers on how to set up CI; we
>> may help Foundation to set up Marketplace in such a way that would
>> allow to automatically consume test artifacts from driver owners; we
>> may provide guidance to Foundation about which features are more
>> important to reflect that in Marketplace; but I would hope we don't
>> put the Neutron team on the hook to validate each driver, or even
>> police CI owners to produce consumable results. (The stick in the
>> latter case would be driver not showing up in Marketplace, or showing
>> up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?

I think it's B, but under Neutron team supervision. As a first step,
we would need to come up with an objective way to compare existing
drivers, and anarchy in how they execute tests, set up environment,
and publish artifacts won't make it easy.

I believe that as long as vendor CI setups are in line with our
guidelines (execute all tests and pass them, configure api_extensions
in tempest.conf to explicitly enumerate supported extensions), then we
can feed test artifacts into Marketplace, where a driver would get a
'supported'/'tested' badge for each extension enumerated in
tempest.conf as long as the latest run is success. If test run failed,
or an extension was not enumerated, then we don't have information
about whether it works with the driver, and hence will show N/A or
Unsupported in corresponding per-feature column.

Of course I assume here that support information useful to users is of
extension granularity. I think that's a reasonable assumption and is
in line with how Networking API is supposed to be consumed. We may
introduce additional tempest flags for special cases like ipv6 support
(already present) if better granularity is needed.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Armando M.]

On 24 January 2017 at 12:46, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
>

Even though I am not the one running, I am replying here because I feel
compelled as outgoing PTL and member of the core team to help the soon PTL
elect through this process.

In my opinion, the first thing to address is to lay down the foundations
for an objective comparison across drivers. The neutron team is obviously
best position in doing that. This was started with how we chose to organize
the neutron project, what quality criteria mattered for the team, and how
qualifying neutron features can be tracked across releases (e.g. still work
in progress in [1]).

Only after we have these solid foundations in place, we can go about the
effort of tracking the wider ecosystem of neutron plugins, and identify who
is best positioned to keep that snapshot accurate over time.

My 2c
Armando

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


> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Jeremy Stanley]

On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > I'm on board with getting visibility into the drivers with improvements to
> > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > 'validation'. Core reviewers don't frequently have access to the hardware or
> > software required to validate these drivers so we can't be sure if the
> > features really are working as expected.
> >
> > If validation is as flexible as you highlighted in the email, we can at
> > least get it to a point where all recent CI runs are linkable from driverlog
> > and people can see recent tempest runs. I don't foresee the Neutron team
> > getting to a point soon where we vouch for certain drivers though just
> > because it is so hard to keep up with their changes (even ignoring changes
> > in the vendor hardware itself).
> 
> Good point. We may guide plugins and drivers on how to set up CI; we
> may help Foundation to set up Marketplace in such a way that would
> allow to automatically consume test artifacts from driver owners; we
> may provide guidance to Foundation about which features are more
> important to reflect that in Marketplace; but I would hope we don't
> put the Neutron team on the hook to validate each driver, or even
> police CI owners to produce consumable results. (The stick in the
> latter case would be driver not showing up in Marketplace, or showing
> up with no feature support information.)

I guess the question I have is who, then, can tell our
operators/users what Neutron drivers are reasonably supported? It
sounds like you're saying Neutron developers are not well-placed to
determine that, which leaves us with these other options:

A. Have the OpenStack Foundation as maintainers of the Marketplace
   decide which Neutron drivers are usable (they don't really staff
   for this purpose so would be throwing darts I think)

B. Trust the driver authors to declare whether they're supported and
   what features they provide (maybe that works better than I
   expect?)

C. Identify another party with a vested interest in validating
   driver support (a board of operators from different organizations
   maybe?)

D. Provide links/aggregation of QA/CI and let the consumers attempt
   to divine supportability for themselves (seems a bit downstream
   hostile)

Are any of those options preferable?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Morales, Victor]

Definitely, both are great candidates and my best wishes to both during this 
process.

Given the latest issues related with the memory consumption[1] in CI jobs, I’m 
just wondering if you have a plan to deal and/or improve it in Neutron.

Regards,
Victor Morales
irc: electrocucaracha





[1] https://bugs.launchpad.net/neutron/+bug/1656386


On 1/24/17, 12:51 PM, "Ihar Hrachyshka"  wrote:

>On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
>> I'm on board with getting visibility into the drivers with improvements to
>> driverlog, etc. What I'm uncertain of is providing much in the lines of
>> 'validation'. Core reviewers don't frequently have access to the hardware or
>> software required to validate these drivers so we can't be sure if the
>> features really are working as expected.
>>
>> If validation is as flexible as you highlighted in the email, we can at
>> least get it to a point where all recent CI runs are linkable from driverlog
>> and people can see recent tempest runs. I don't foresee the Neutron team
>> getting to a point soon where we vouch for certain drivers though just
>> because it is so hard to keep up with their changes (even ignoring changes
>> in the vendor hardware itself).
>
>Good point. We may guide plugins and drivers on how to set up CI; we
>may help Foundation to set up Marketplace in such a way that would
>allow to automatically consume test artifacts from driver owners; we
>may provide guidance to Foundation about which features are more
>important to reflect that in Marketplace; but I would hope we don't
>put the Neutron team on the hook to validate each driver, or even
>police CI owners to produce consumable results. (The stick in the
>latter case would be driver not showing up in Marketplace, or showing
>up with no feature support information.)
>
>Ihar
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> I'm on board with getting visibility into the drivers with improvements to
> driverlog, etc. What I'm uncertain of is providing much in the lines of
> 'validation'. Core reviewers don't frequently have access to the hardware or
> software required to validate these drivers so we can't be sure if the
> features really are working as expected.
>
> If validation is as flexible as you highlighted in the email, we can at
> least get it to a point where all recent CI runs are linkable from driverlog
> and people can see recent tempest runs. I don't foresee the Neutron team
> getting to a point soon where we vouch for certain drivers though just
> because it is so hard to keep up with their changes (even ignoring changes
> in the vendor hardware itself).

Good point. We may guide plugins and drivers on how to set up CI; we
may help Foundation to set up Marketplace in such a way that would
allow to automatically consume test artifacts from driver owners; we
may provide guidance to Foundation about which features are more
important to reflect that in Marketplace; but I would hope we don't
put the Neutron team on the hook to validate each driver, or even
police CI owners to produce consumable results. (The stick in the
latter case would be driver not showing up in Marketplace, or showing
up with no feature support information.)

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL Candidacy

[Armando M.]

Hi neutrinos,

No, it's not what you might be thinking...I am just delighted to see two
excellent candidates willing to take the reins of the project going forward
[1,2].

I couldn't hope for more enthusiasm; best of luck to both candidates and
anyone else who is going to step up! This is exciting!

Cheers,
Armando

[1] https://review.openstack.org/#/c/423552/
[2] https://review.openstack.org/#/c/424500/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Kevin Benton]

I'm on board with getting visibility into the drivers with improvements to
driverlog, etc. What I'm uncertain of is providing much in the lines of
'validation'. Core reviewers don't frequently have access to the hardware
or software required to validate these drivers so we can't be sure if the
features really are working as expected.

If validation is as flexible as you highlighted in the email, we can at
least get it to a point where all recent CI runs are linkable from
driverlog and people can see recent tempest runs. I don't foresee the
Neutron team getting to a point soon where we vouch for certain drivers
though just because it is so hard to keep up with their changes (even
ignoring changes in the vendor hardware itself).

On Mon, Jan 23, 2017 at 12:33 PM, Mike Perez  wrote:

> On 18:35 Jan 22, Kevin Benton wrote:
> > I would like to propose my candidacy for the Neutron PTL.
> >
> > I have been contributing to Neutron since the Havana development
> > cycle working for a network vendor and then a distribution vendor.
> > I have been a core reviewer since the Kilo development cycle and
> > I am on the Neutron stable maintenance team as well as the drivers
> > team.
> >
> > I have a few priorities that I would focus on as PTL:
>
> Do you have any thoughts/plans with plugin validation? [1][2][3]
>
> [1] - http://lists.openstack.org/pipermail/openstack-dev/2017-Janu
> ary/110151.html
> [2] - https://review.openstack.org/#/c/391594/
> [3] - https://etherpad.openstack.org/p/driverlog-validation
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL candidacy

[Ihar Hrachyshka]

Hi team,

I would like to propose my PTL candidacy for Pike.

Some of you already know me. If not, here is my brief OpenStack bio. I
joined the community back in Havana, and managed to stick around till
now. During the time, I fit several project roles like serving as a
Neutron liaison of different kinds (stable, oslo, release), fulfilling
my Neutron core reviewer duties, taking part in delivering some
longstanding features, leading QoS and upgrades subteams, as well as
being part of Neutron Drivers team. I also took part in miscellaneous
cross project efforts.

I think my experience gives me broad perspective on how the OpenStack
community and more specifically Networking works, and what is expected
from its PTL.

First, let me describe my vision of PTL role.

* It's not only about technical intricacies. It's also about people
and procedures that make the project run smoothly day by day. The role
of PTL is in empowering other team members, keeping track of any
roadblocks and inconveniences that the team have, and working on
streamlining workflow.

* It's about delegation. We should make it a habit to look at the list
of potential candidates for core membership and other leadership and
administrative positions not just in times we are short on existing
members.

* PTL should be transparent and replaceable. I will work with outgoing
PTL to capture oral wisdom and state of affairs into a publicly
accessible project dashboard, and I will continue sharing such
information with the team on constant basis. The project dashboard
will give you answers to questions like: what's the project direction?
what are current priorities, and where does each stand?  what's on PTL
and Drivers' mind? which cross-project and governance initiatives are
currently worked on? etc.

As PTL, I'd like to focus on the following things:

* Speed up the RFE/spec process. We should manage RFE/spec review
pipeline in such a way so that initiatives that are given a green
light on writing up design details get timely feedback and can get
past spec process in reasonable time.  At the same time we should be
honest to the community not to accept proposals that have high risk to
fall through cracks due to lack of manpower. I will encourage usage of
reviewday and other tools to keep focus of the team. We will mull over
the idea of virtual code sprints for high demand topics.

* Continue Stadium program without drastic changes of direction.
Thanks to Armando, we filled the Stadium with tangible meaning. I want
us to build on top of that foundation to drive consistency and high
quality standards between participating projects.

* Support Marketplace rework. With huge number of drivers and plugins
available for Neutron, it became hard for operators to pick the right
one and for vendors to advertise their features. There is strong
vendor interest to improve situation there. We should boost Feature
Classification work, and integrate it with how third party CI systems
report test results so that they become useful for Marketplace.

* Introduce Gate Keeper role. We've recently made significant progress
in how we deal with gate: we expanded coverage to new types of jobs,
we utilize Grafana and other community tools, we review gate-failure
tagged bugs during weekly meetings. Sadly, sometimes gate becomes
unstable, and it slows down work progress for everyone.  In such
cases, it's all about timely addressing the issue. For that matter, I
will work with the team on defining a new Gate Keeper role that would
help prioritizing current gate issues, as well as proactively work
with the team on gate instability vectors. I believe clear ownership
is the key.

* Make centralized L3 legacy indeed. We have DVR and HA in tree for
quite some time. Both technologies are now mature enough, and are no
longer mutually exclusive. Sadly, they are still second class citizens
in our own gate.  My belief is we should give users a clear signal
that old L3 is indeed legacy by switching our jobs to DVR+HA where
applicable.  I am sure that will surface some previously unknown
issues, but we'll be ready to tackle them.  While it's never black or
white, I suggest we prioritize this work over adding new major L3
features.

* Support existing maintenance initiatives. I'd like us to close
neutron-lib saga in Pike, and consider neutron-lib switch for a
requirement to all Stadium projects starting from Queens. We should
also close OSC transition during Pike.

* Explore alternative ways to evolve Neutron API.  Piling up
extensions and allowing third parties to completely change core
resource behaviour is not ideal, and now that api-ref and API
consolidation effort in neutron-lib are closer to completion, we may
have better answers to outstanding questions than during previous
attempts to crack the nut. I would like to restart the discussion some
time during Pike.

Now, you may ask, it's a nice list of things to do, but we can't
manage to handle all of that in one cycle, can we? Well, 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Mike Perez]

On 18:35 Jan 22, Kevin Benton wrote:
> I would like to propose my candidacy for the Neutron PTL.
> 
> I have been contributing to Neutron since the Havana development
> cycle working for a network vendor and then a distribution vendor.
> I have been a core reviewer since the Kilo development cycle and
> I am on the Neutron stable maintenance team as well as the drivers
> team.
> 
> I have a few priorities that I would focus on as PTL:

Do you have any thoughts/plans with plugin validation? [1][2][3]

[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
[2] - https://review.openstack.org/#/c/391594/
[3] - https://etherpad.openstack.org/p/driverlog-validation

-- 
Mike Perez


pgpxgOUqLRXO4.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Jay Pipes]

On 01/22/2017 09:35 PM, Kevin Benton wrote:

I would like to propose my candidacy for the Neutron PTL.

I have been contributing to Neutron since the Havana development
cycle working for a network vendor and then a distribution vendor.
I have been a core reviewer since the Kilo development cycle and
I am on the Neutron stable maintenance team as well as the drivers
team.

I have a few priorities that I would focus on as PTL:

* Cleanup and simplification of the existing code: In addition to
supporting the ongoing work of converting all data access into OVO
models, I would like the community to continue breaking down code using
the callback event system. We should eliminate as many
extension-specific mixins and special-cases from the core as possible so
it becomes very easy to reason about and stable from a code-churn
perspective. This approach forces us to add appropriate event
notifications to the core to build service plugins and drivers out of
tree without requiriing modifications to the core.


++ Great initiative, Kevin.

-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] PTL Candidacy

[Kevin Benton]

I would like to propose my candidacy for the Neutron PTL.

I have been contributing to Neutron since the Havana development
cycle working for a network vendor and then a distribution vendor.
I have been a core reviewer since the Kilo development cycle and
I am on the Neutron stable maintenance team as well as the drivers
team.

I have a few priorities that I would focus on as PTL:

* Cleanup and simplification of the existing code: In addition to
supporting the ongoing work of converting all data access into OVO models,
I would like the community to continue breaking down code using the
callback event system. We should eliminate as many extension-specific
mixins and special-cases from the core as possible so it becomes very easy
to reason about and stable from a code-churn perspective. This approach
forces us to add appropriate event notifications to the core to build
service plugins and drivers out of tree without requiriing modifications to
the core.

* Reinstating VPNaaS: this project accomplishes its goals reasonably well
and it solves a clear use case. There has been enough interest from
contributors on the mailing list that we should be able to find enough
resources to at least keep it maintained even if no large features are
added.

* Switch to Pecan and eliminate old API code: we have been working on the
new Pecan rewrite for several cycles now. With the current patches open for
review, we have parity with the existing API and it should be safe to
switch.

* Enhance DVR to solve additional use cases requested by the community: I
would like us to enable SNAT at the compute nodes for cases where
consumption of IPs for each compute ndoe from the external network is not a
concern. I would also like us to allow the central node to provide floating
IP translations for ports unserviced by DVR local nodes (e.g. unbound
ports, baremetal ports, ports on compute nodes not attached directly to the
external network).

* Bring on new core reviewers: we suffered from attrition of our core team
during this last cycle due to some fundamental changes at a few of the
major contributing companies. We have several strong contributors that I
would like to see take on a core reviewer role so we can keep our review
backlog under control.

* Support services being built on Neutron: whether it's BGPVPN, Kuryr, SFC,
Octavia, Ironic, or whatever else, I want Neutron to provide the building
blocks and primitives necessary to fulfill the needs of these projects.
This means supporting initiatives like neutron-lib, agent extensions, and
future API enhancements to provide more control over core resource behavior.

* Add tooling to keep the review backlog under control: I would like to
look into a bot that can harass us in the channel if a patch sits for too
long without feedback. I want to avoid having patches sit in our queue for
months at a time because it results in fixes falling through the cracks.


Cheers,
Kevin Benton (kevinbenton)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL Candidacy

[Gary Kotton]

Hi,
I saw that Armando has put himself up for reelection. I would like to endorse 
him and vote a big +1 for him doing the job in the next cycle. One of the hard 
things about working in this environment is that it is very hard to get any 
feedback. I think that over the last cycle you have grown and have done a very 
good job.
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] PTL Candidacy

[Armando M.]

I would like to propose my candidacy for the Neutron PTL.

I have been the Neutron PTL for the Mitaka release, and I would like to
continue the journey on which I have embarked upon a little over six months
ago.

Back then, I had a number of objectives which I wanted to achieve with the
help of the Neutron team, and with this candidacy statement I would like to
take the opportunity to look back and see what we have accomplished and
what else is waiting ahead of us:

   - Stability is the priority: I have introduced a rotation mechanism for
   triaging and staying on top of bugs; with that, we have a very little
   percentage of bugs that go unacknowledged, and even though we only managed
   to fix only 60% of all bugs reported in the Mitaka timeframe, some might
   regard this as a remarkable achievement. I also made sure the Neutron
   projects was amongst the most stable one, by aggressively addressing
   intermittent failures, and by ensuring that failures did not impact the
   integrated gate. As of today, the success rate for Neutron (alone) is at
   >98%. We also worked hard to extend test coverage to DVR, Linuxbridge and
   Grenade multinode. Going forward, I'd like to focus on improving the
   stability of multinode jobs, and look at how we can do more reliable and
   exhaustive performance testing on a more regular basis.
   - Narrow the focus: we all know by now my attempt to address the needs
   and the issues of the Stadium, and the team effort aimed at standing up
   neutron-lib to allow for Neutron projects to loosely couple together. The
   journey is far from being over and I will continue to work towards a
   resolution that strikes a good compromise for everybody. On the other end,
   I worked hard with the rest of the drivers team members to ensure a
   coherent strategy and vision when assessing and approving RFE's. I proposed
   process changes to ensure that reviewers and contributors can be more
   focussed and work together towards a well defined goal.
   - Consistency is paramount: promoting the documentation of our practices
   (like our deputy, blueprint/rfe guidelines and release postmortem), as well
   as starting the 'Effective Neutron' guide have been two key areas that
   allowed our developers to have a common understanding on how we operate,
   review, develop and manage our project. More needs to be done to ensure we
   become 'more predictable' in terms of the software we produce and the
   quality associated with it, including end-user facing documentation.
   - Define long term strategy: when I started looking at this area,
   Neutron had 400+ blueprints targeted. I tried to put some sanity back into
   the feature submission process by limiting who can actually submit feature
   proposals (the drivers team) and by cleaning up the huge backlog of
   blueprints we had (currently we have 15 blueprints and 19 RFEs). That said
   this is an area where I feel I have not made enough of a dent to be
   satisfied. This is somewhat tangential to the needs of the Stadium, but I
   think we need more time to execute a plan of action that can yield positive
   results.
   - Keep developers and reviewers _aware_: I worked relentlessly to remind
   our reviewers to stay focussed and review what matters for a given release.
   I think we have achieved this with mixed success, and I know that some of
   us worked hard to give us the tools to help us stay more aware.
   - I would like to promote a 'you merge it, you own it' type of
   mentality: this is typically done by leading by example, and I am pleased
   to see that many of us take great pride in the code they review and merge.
   We need to continue to promote this attitude.

And last but not least:

   - Improve the relationships with other projects: Nova and QA primarily.
   I personally feel that we went a long way to improve these relationships,
   from the technical front (for example by improving the provisioning
   workflow of networking resources for Nova instances - aka get-me-a-network,
   and by tackling the testing issues affecting Neutron) to the the social
   front, by having a good representation of contributors across multiple
   projects at the various mid-cycle events. There is always room for
   improvement, of course!

If you liked what I did/said, then allow me to continue.

Thanks for reading and, as usual, forgive the typos!
Armando Migliaccio (aka armax)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] PTL Candidacy

[Armando M.]

I would like to propose my candidacy for the Neutron PTL.

If you are reading this and you know me, then you probably know what I have
been up to up until now, what I have done for the project, and what I may
continue to do. If you do not know me, and you are still interested in
reading, then I will try not bore you.

As member of this project, I have been involved with it since the early
days, and I have served as core developer since Havana. If you are
wondering whether I am partially to blame for the issues that affect
Neutron, well you may have a point, but keep reading...

I believe that Neutron itself is a unique project and as such has unique
challenges. We have grown tremendously mostly propelled by a highly
opinionated vendor perspective. This has caused us some problems and we set
foot a cycle or so ago to fix these, but at the same time stay true to the
nature of our mission: define logical abstractions, and related
implementations to provide on-demand, cloud oriented networking services.

As any other project in OpenStack, we are software and we mostly implement
'stuff' in software, and because of that we are prone to all the issues
that a software project may have. To this aim, going forward I would like
us to improve the following:


   - Stability is the priority: new features are important, but complete
   and well tested existing features are more important; we gotta figure out a
   way to bring the number of bugs down to a manageable number, just like
   nations are asked to keep their sovereign debt below a certain healthy
   threshold.
   - Narrow the focus: now that the Neutron 'stadium' is here with us,
   external plugins and drivers can integrate with Neutron in a loosely
   manner, giving the core the opportunity to be more razor focus at getting
   better at what we do: logical abstractions and pluggability.
   - Consistency is paramount: having grown the review team drastically
   over the past cycle, it is easy to skew quality in one area over an other.
   We need to start defining common development and reviewer practices so
   that, even though we deal are made of many sub-projects and modules, we
   operate, feel and look like one...just like OpenStack :)
   - Define long term strategy: we need to have an idea where Neutron start
   and where Neutron end. At some point, this project will reach enough
   maturity where we feel like we are 'done' and that's okay. Some of us will
   move on to the next big thing.
   - Keep developers and reviewers _aware_: we all have to work
   collectively towards a common set of goals, defined by the release cycle.
   We will have to learn to push back on _random_ forces that keep distracting
   us.
   - I would like to promote a 'you merge it, you own it' type of
   mentality: even though we are pretty good at it already, we need a better
   balance between reviews and contributions. If you bless a patch, you got to
   be prepared to dive into the issues that it may potentially causes. If you
   bless a patch, you got to be prepared to improve the code around it, and so
   on. You will be a better reviewer if you learn to live with the pain of
   your mistakes. This is he only way to establish a virtuous cycle where
   quality improves time over time.

And last but not least:


   - Improve the relationships with other projects: Nova and QA primarily.
   We should allocate enough bandwidth to address integration issues with Nova
   and the other emerging projects, so that we stay plugged with them. QA is
   also paramount so that no-one is gonna hate us because we send the gate
   belly up. As for nova-network, I must admit I am highly skeptical by now:
   if our community were a commercial enterprise trying to solve that problem
   we would have ran out of money long time ago. We tried time and time again
   to crack this nut open, and even though we made progress in a number of
   areas, we haven't really budged where some people felt it mattered. We need
   to recognize that the problem is not just technical...it is social; no-one,
   starting from the developers and the employers behind them, seems to be
   genuinely concerned with the need of making nova-network a thing of the
   past. They have other priorities, they are chasing new customers, they want
   to disrupt Amazon. None of this nova-network deprecation drama fits with
   their agendas and furthermore, even if we found non-corporate sponsored
   developers willing to work on it, let's face it migration is a problem that
   is really not that interesting to solve. So where do we go from here? I do
   not have a clear answer yet. However, I think we all agree that the Neutron
   team wants to make Neutron a better product, more aligned with the needs of
   our users, but we must recognize that _better_ does not mean *like*
   nova-network, because the two products are not the same and they never will
   be.

Ok, now that you read this, you are ready to know whether you may want 

[openstack-dev] [Neutron] PTL Candidacy

[Rossella Sblendido]

Hi everyone,

I decided to run for the Neutron PTL position for the Mitaka release
cycle.

I have been contributing to Neutron since Havana and I am a member of
the control plane core review team. During these years I have touched
most parts of the Neutron code and in the last cycle my main focus has
been to restructure the OVS agent, adding the ability to use events
provided by ovsdb client and making it more resilient to failures.

Mentoring people and spreading knowledge about Neutron have been high
priorities for me in these years. I am a regular speaker at OpenStack
events (local meetups, Openstack days and summits), where my talks have
had high attendance and good feedback.
I have been a mentor for the Outreachy program [1] and the OpenStack
upstream training.

If I become PTL these are my main objectives for Mitaka:

* Make the community even more welcoming.
Neutron is still facing a big challenge in terms of review bandwidth.
Good features can't get merged because of this limit. Even if the
introduction of the Lieutenant system [2] has improved scalability, we
still need to create a better way to share knowledge.
In addition to improving the existing documentations and tutorials I'd
like to create a team of mentors that can help new contributors (the
quality of the proposed patches should increase so that the review time
needed to merge them should decrease) and form new reviewers (more good
people, more bandwidth).

* Keep working hard to increase the stability.
The introduction of functional tests and full stack tests was great, we
just need to keep going in that direction. Moreover I'd love to produce
and store some benchmark data so that we can also keep track of the
performance of Neutron during time.

* Continue getting feedback from operators.
I think it's very important to hear the opinions of the actual Neutron
users and to understand their concerns.

* Paying down technical debt
Introduce oslo versioned objects to improve RPC and keep refactoring
Neutron code to make it more readable and understandable.

Before proposing my candidacy I made sure I have the full support of my
employer for this role.

Neutron has a great team of contributors and great leaders, it would be
an honor for me to be able to coordinate our efforts and push Neutron
forward.


Thanks for reading so far and for considering this candidacy,

Rossella (rossella_s)

[1] https://wiki.openstack.org/wiki/Outreachy
[2]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/02/2015 10:16 AM, Kyle Mestery wrote:
 Hi everyone:
 
 I'd like to announce my candidacy for another term as the Neutron PTL. I'm
 the current Neutron PTL, having been the Neutron PTL for the past two
 cycles (Juno and Kilo). I'd like a chance to lead the Neutron team for
 another cycle of development.
 
 During the Kilo cycle, we worked hard to expand the capabilities of all
 contributors in Neutron. Some examples include the following:
 
 * Plugin decomposition [1] has allowed us to enhance innovation and speed
 around plugin and driver development in Neutron.
 * Moving our API tests into the Neutron tree from Tempest has allowed us to
 better control our API testing destiny.
 * The advanced services split [2] has allowed us to continue to scale
 development of Neutron by breaking out the advanced services into their own
 repositories, with separate core reviewer teams.
 
 These changes have helped to increase the velocity of development for all
 parties involved, and yet still maintain testing quality to ensure
 stability of code. I'm proud of the work the team has done in this area.
 These are the types of things the team needed to do in order to put Neutron
 into solid ground to continue development in upcoming cycles.
 
 Looking forward to Liberty, we have a backlog of specs from Kilo which we
 hope to land early in Liberty. Things such as pluggable IPAM [3] and the
 flavor framework [4] are things which never quite made Kilo and will be
 fast tracked into development for Liberty. In addition, we have a large
 list of items people are interested in discussing at the upcoming Summit
 [5], we'll work to pare that list down into the things we can deliver for
 Liberty.
 
 Being PTL is effectively a full time job, and in a lot of cases it's even
 more than a full time job. What makes it rewarding is being able to work
 with a great group of upstream contributors as you work towards common
 goals for each release. I'm proud of the work the Neutron team has done for
 the Juno and Kilo cycles, and I graciously look forward to the chance to
 lead the team during the upcoming Liberty cycle.
 
 Thank you!
 Kyle
 
 [1]
 http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html
 [2]
 http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html
 [3]
 http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-ipam.html
 [4]
 http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html
 [5] https://etherpad.openstack.org/p/liberty-neutron-summit-topics
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL Candidacy

[Kyle Mestery]

Hi everyone:

I'd like to announce my candidacy for another term as the Neutron PTL. I'm
the current Neutron PTL, having been the Neutron PTL for the past two
cycles (Juno and Kilo). I'd like a chance to lead the Neutron team for
another cycle of development.

During the Kilo cycle, we worked hard to expand the capabilities of all
contributors in Neutron. Some examples include the following:

* Plugin decomposition [1] has allowed us to enhance innovation and speed
around plugin and driver development in Neutron.
* Moving our API tests into the Neutron tree from Tempest has allowed us to
better control our API testing destiny.
* The advanced services split [2] has allowed us to continue to scale
development of Neutron by breaking out the advanced services into their own
repositories, with separate core reviewer teams.

These changes have helped to increase the velocity of development for all
parties involved, and yet still maintain testing quality to ensure
stability of code. I'm proud of the work the team has done in this area.
These are the types of things the team needed to do in order to put Neutron
into solid ground to continue development in upcoming cycles.

Looking forward to Liberty, we have a backlog of specs from Kilo which we
hope to land early in Liberty. Things such as pluggable IPAM [3] and the
flavor framework [4] are things which never quite made Kilo and will be
fast tracked into development for Liberty. In addition, we have a large
list of items people are interested in discussing at the upcoming Summit
[5], we'll work to pare that list down into the things we can deliver for
Liberty.

Being PTL is effectively a full time job, and in a lot of cases it's even
more than a full time job. What makes it rewarding is being able to work
with a great group of upstream contributors as you work towards common
goals for each release. I'm proud of the work the Neutron team has done for
the Juno and Kilo cycles, and I graciously look forward to the chance to
lead the team during the upcoming Liberty cycle.

Thank you!
Kyle

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html
[3]
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-ipam.html
[4]
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html
[5] https://etherpad.openstack.org/p/liberty-neutron-summit-topics
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Anita Kuno]

confirmed

On 03/31/2014 01:04 PM, Kyle Mestery wrote:
 Hi everyone,
 
 I have decided to run for the OpenStack Networking (Neutron) PTL position.
 
 Why I Want To Be Neutron PTL
 -
 I want to be Neutron PTL because I wish to continue pushing Neutron forward
 and help it evolve, and have the skills necessary to do it. I've worked in 
 Open
 Source for many years, having contributed to projects such as Open vSwitch,
 libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a great
 team of developers, both core and non-core contributors. Being able to help
 them all work productively together and push Neutron forward is something I
 not only want to do, but something I think I can be very effective at.
 
 Qualifications
 -
 I have been a core developer since the beginning of the Havana cycle. My
 main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
 which I've co-lead for the last year. I wrote the OpenDaylight ML2
 driver, as well
 as the devstack integration and Jenkins setup for OpenDaylight. I have also
 been leading a sub-team focused on Group Based Policy since the Icehouse
 Summit. As on Open vSwitch developer, my focus has been on improving
 Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
 Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
 from the OpenStack community to an audience in the upper Midwest. I've
 presented at the last few OpenStack Summits on Open Source SDN topics, as
 well as giving presentations on OpenStack at other Open Source conferences. I
 recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
 developers to interact with not only each other but also developers from
 OpenStack Neutron and OpenDaylight.
 
 Icehouse Accomplishments
 -
 This past cycle, my main focus was continuing to expand the ML2 sub-team and
 assist plugin developers who were porting their existing core plugins
 into ML2 or
 writing brand new ML2 drivers. I also formed and lead the Group Based Policy
 sub-team, which is now marching towards a Proof of Concept for the Juno Summit
  In addition, I've spent time with the OpenDaylight project to ensure that
 OpenDaylight integrates with OpenStack Neutron as an ML2 driver.
 
 Looking forward to Juno
 -
 If I am elected PTL, I'd like to focus on a few areas for Neutron. One 
 immediate
 area of improvement I'd like to do is around the blueprint process. I've been
 watching what Russell and the Nova team have been doing with setting up the
 Nova BP process to use gerrit, and I'd like to move Neutron in this
 direction as well.
 Formalizing this process a bit more will lead to less surprises for BP
 drafters, and
 will also ensure core reviewers know what they are signing up for as
 people propose
 features. I'd also like to work to expand our core reviewer team in
 the Juno cycle. As
 the project has grown, the existing core reviewers could use some assistance 
 by
 working to expand the team and spread the review load. Along these
 lines, I'd also
 like to empower the sub-teams in Neutron. The project has grown to a point 
 where
 empowering the various sub-teams to allow more effective decision
 making would be
 a good thing. I'd like to continue the focus on ensuring Neutron is a
 good citizen in
 the community by ensuring we squash bugs related to the gate. And
 finally, I want to
 work to ensure we have a scalable, production quality Open Source
 Neutron reference
 implementation in the Juno timeframe.
 
 In closing
 -
 OpenStack Neutron has taken a big step forward in the Icehouse cycle
 with regards to
 stability and testing. Ensuring we continue to enhance the development
 process will
 allow us to continue making strides in this area and allow Neutron to
 continue evolving
 in a positive direction.
 
 Thank you,
 Kyle
 
 ___
 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] PTL Candidacy

[CôngTT]

Thanks anh. Lúc chiều e cũng bookmark bài này rồi. E phải xem kỹ phần kiến
trúc trong neutron, phần network này vẫn chưa thông lắm anh ạ.

P/s: Anh gửi tài liệu OVS cho e và Long nhé.
On 1 Apr 2014 00:04, Kyle Mestery mest...@noironetworks.com wrote:

 Hi everyone,

 I have decided to run for the OpenStack Networking (Neutron) PTL position.

 Why I Want To Be Neutron PTL
 -
 I want to be Neutron PTL because I wish to continue pushing Neutron forward
 and help it evolve, and have the skills necessary to do it. I've worked in
 Open
 Source for many years, having contributed to projects such as Open vSwitch,
 libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a
 great
 team of developers, both core and non-core contributors. Being able to help
 them all work productively together and push Neutron forward is something I
 not only want to do, but something I think I can be very effective at.

 Qualifications
 -
 I have been a core developer since the beginning of the Havana cycle. My
 main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
 which I've co-lead for the last year. I wrote the OpenDaylight ML2
 driver, as well
 as the devstack integration and Jenkins setup for OpenDaylight. I have also
 been leading a sub-team focused on Group Based Policy since the Icehouse
 Summit. As on Open vSwitch developer, my focus has been on improving
 Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
 Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
 from the OpenStack community to an audience in the upper Midwest. I've
 presented at the last few OpenStack Summits on Open Source SDN topics, as
 well as giving presentations on OpenStack at other Open Source
 conferences. I
 recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
 developers to interact with not only each other but also developers from
 OpenStack Neutron and OpenDaylight.

 Icehouse Accomplishments
 -
 This past cycle, my main focus was continuing to expand the ML2 sub-team
 and
 assist plugin developers who were porting their existing core plugins
 into ML2 or
 writing brand new ML2 drivers. I also formed and lead the Group Based
 Policy
 sub-team, which is now marching towards a Proof of Concept for the Juno
 Summit
  In addition, I've spent time with the OpenDaylight project to ensure that
 OpenDaylight integrates with OpenStack Neutron as an ML2 driver.

 Looking forward to Juno
 -
 If I am elected PTL, I'd like to focus on a few areas for Neutron. One
 immediate
 area of improvement I'd like to do is around the blueprint process. I've
 been
 watching what Russell and the Nova team have been doing with setting up the
 Nova BP process to use gerrit, and I'd like to move Neutron in this
 direction as well.
 Formalizing this process a bit more will lead to less surprises for BP
 drafters, and
 will also ensure core reviewers know what they are signing up for as
 people propose
 features. I'd also like to work to expand our core reviewer team in
 the Juno cycle. As
 the project has grown, the existing core reviewers could use some
 assistance by
 working to expand the team and spread the review load. Along these
 lines, I'd also
 like to empower the sub-teams in Neutron. The project has grown to a point
 where
 empowering the various sub-teams to allow more effective decision
 making would be
 a good thing. I'd like to continue the focus on ensuring Neutron is a
 good citizen in
 the community by ensuring we squash bugs related to the gate. And
 finally, I want to
 work to ensure we have a scalable, production quality Open Source
 Neutron reference
 implementation in the Juno timeframe.

 In closing
 -
 OpenStack Neutron has taken a big step forward in the Icehouse cycle
 with regards to
 stability and testing. Ensuring we continue to enhance the development
 process will
 allow us to continue making strides in this area and allow Neutron to
 continue evolving
 in a positive direction.

 Thank you,
 Kyle

 ___
 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] [Neutron] PTL Candidacy

[Mark McClain]

All-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL and would like to continue leading our team during 
the Juno cycle.  As PTL, I have worked to promote a vibrant open ecosystem of 
deployers, integrators and vendors within Neutron.  Our openness is exemplified 
by the new drivers/plugins, new contributors, and diversity of sub team 
leadership in Icehouse.

Qualifications
---
I have been a contributor to Neutron since Essex and a core team member since 
Folsom.  I have been developing software with Python professionally for 14 
years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
Neutron code base, I have worked extensively on DHCP, IP library, network 
namespaces, metadata services, database migrations, and LBaaS reference 
implementation.  I frequently present Neutron at local and regional OpenStack 
events to build community by engaging new developers, deployers, and 
integrators.

I am the top reviewer during the Icehouse cycle:
http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt

I am the top reviewer since the inception of Neutron:
http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt

Icehouse

As the technical lead during Icehouse, I kicked off the initiative to improve 
testing within Neutron.  This initiative included the creation of the mid-cycle 
sprint that brought the QA and Neutron teams together.  The successful sprint  
produced a more stable Neutron core, more API test coverage, the soon-to-be 
enabled full Tempest and Grenade jobs and a more connected community.  
Additionally, I promoted the policy of improve 3rd party testing of 
plugin/driver code from vendors [1].  This initiative has resulted in a more 
thoroughly tested and stable driver/plugin codebase for operators to deploy.

Juno
---
My vision for Juno is that our team continue to build upon the open environment 
that enables all vendors, deployers and integrators the opportunity to 
contribute to the development of Neutron.  During the cycle, I believe our team 
should focus on a few core initiatives:

* Nova Parity
We committed to delivering Nova Parity when Neutron was accepted as an 
Integrated project.  By delivering Distributed Virtual Routing, Nova-Network to 
Neutron migration, testing and documentation we will be following through on 
our commitment to the greater OpenStack community.

* Advanced Services
The team should implement a multi-vendor ‘flavor' API that provides tenants an 
easy to use API, deployers a choice and vendors an opportunity to innovate.  
This API should complement the existing APIs our teams have created over the 
last two cycles.  Additionally, we should add secure APIs and agent code to 
support SSL termination for LBaaS and SSL VPNs.

* Process Improvements
Our team has grown, but our processes for submitting and reviewing blueprints 
has largely stayed the same which has made the review process uneven. As the 
Icehouse cycle has wound down, I have been working to put new infrastructure in 
place to improve the blueprint process for Juno[2].  The new process should 
ensure a more consistent experience for all contributors in Juno.  In addition 
to refining the blueprint process, our sub team structure should be revised to 
improve communication, remove blockers, and facilitate more efficient reviews.

* Internal API and REST API Improvements
We have several exciting new features in development for Neutron, but at times 
our internal APIs have inhibited efficient implementation of these features.  
During the Juno cycle, we should begin the process of revising our internal 
interfaces to enable easier IPv6, migration to Python 3 and development of 
plugins/drivers and services,

* Group Policy
There is significant community interest in adding policy support to Neutron.  
During Juno, we should work on implementing the first iteration of the policy 
API extension.  This extensions will be aided by the work to improve the 
internal API.

* Testing
The team made significant testing gains during Icehouse.  We should build on 
that work during Juno and collaborate with the QA team to further refine and 
improve our testing through additional scenarios, varied migration 
configurations and functional tests.

* Documentation
Good documentation is a requirement for both deployers and developers we have 
made improvements to both Icehouse.  For Juno, I’d like to continue this work 
as it is essential for parity.

* Growing our plugin and driver community

See something missing from this list?  As PTL, I’m excited to work with our 
community to refine this list for Juno.


Other OpenStack Contributions
--
* Co-organizer of the Atlanta OpenStack Meetup
* Member of the Technical Committee since the Havana cycle
* Stable Core Team Member
* Requirements Core Team Member

Thanks,
mark

[1] 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Anita Kuno]

confirmed

On 03/31/2014 04:15 PM, Mark McClain wrote:
 All-
 
 I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.
 
 I am the current Neutron PTL and would like to continue leading our team 
 during the Juno cycle.  As PTL, I have worked to promote a vibrant open 
 ecosystem of deployers, integrators and vendors within Neutron.  Our openness 
 is exemplified by the new drivers/plugins, new contributors, and diversity of 
 sub team leadership in Icehouse.
 
 Qualifications
 ---
 I have been a contributor to Neutron since Essex and a core team member since 
 Folsom.  I have been developing software with Python professionally for 14 
 years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
 Neutron code base, I have worked extensively on DHCP, IP library, network 
 namespaces, metadata services, database migrations, and LBaaS reference 
 implementation.  I frequently present Neutron at local and regional OpenStack 
 events to build community by engaging new developers, deployers, and 
 integrators.
 
 I am the top reviewer during the Icehouse cycle:
 http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt
 
 I am the top reviewer since the inception of Neutron:
 http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt
 
 Icehouse
 
 As the technical lead during Icehouse, I kicked off the initiative to improve 
 testing within Neutron.  This initiative included the creation of the 
 mid-cycle sprint that brought the QA and Neutron teams together.  The 
 successful sprint  produced a more stable Neutron core, more API test 
 coverage, the soon-to-be enabled full Tempest and Grenade jobs and a more 
 connected community.  Additionally, I promoted the policy of improve 3rd 
 party testing of plugin/driver code from vendors [1].  This initiative has 
 resulted in a more thoroughly tested and stable driver/plugin codebase for 
 operators to deploy.
 
 Juno
 ---
 My vision for Juno is that our team continue to build upon the open 
 environment that enables all vendors, deployers and integrators the 
 opportunity to contribute to the development of Neutron.  During the cycle, I 
 believe our team should focus on a few core initiatives:
 
 * Nova Parity
 We committed to delivering Nova Parity when Neutron was accepted as an 
 Integrated project.  By delivering Distributed Virtual Routing, Nova-Network 
 to Neutron migration, testing and documentation we will be following through 
 on our commitment to the greater OpenStack community.
 
 * Advanced Services
 The team should implement a multi-vendor ‘flavor' API that provides tenants 
 an easy to use API, deployers a choice and vendors an opportunity to 
 innovate.  This API should complement the existing APIs our teams have 
 created over the last two cycles.  Additionally, we should add secure APIs 
 and agent code to support SSL termination for LBaaS and SSL VPNs.
 
 * Process Improvements
 Our team has grown, but our processes for submitting and reviewing blueprints 
 has largely stayed the same which has made the review process uneven. As the 
 Icehouse cycle has wound down, I have been working to put new infrastructure 
 in place to improve the blueprint process for Juno[2].  The new process 
 should ensure a more consistent experience for all contributors in Juno.  In 
 addition to refining the blueprint process, our sub team structure should be 
 revised to improve communication, remove blockers, and facilitate more 
 efficient reviews.
 
 * Internal API and REST API Improvements
 We have several exciting new features in development for Neutron, but at 
 times our internal APIs have inhibited efficient implementation of these 
 features.  During the Juno cycle, we should begin the process of revising our 
 internal interfaces to enable easier IPv6, migration to Python 3 and 
 development of plugins/drivers and services,
 
 * Group Policy
 There is significant community interest in adding policy support to Neutron.  
 During Juno, we should work on implementing the first iteration of the policy 
 API extension.  This extensions will be aided by the work to improve the 
 internal API.
 
 * Testing
 The team made significant testing gains during Icehouse.  We should build on 
 that work during Juno and collaborate with the QA team to further refine and 
 improve our testing through additional scenarios, varied migration 
 configurations and functional tests.
 
 * Documentation
 Good documentation is a requirement for both deployers and developers we have 
 made improvements to both Icehouse.  For Juno, I’d like to continue this work 
 as it is essential for parity.
 
 * Growing our plugin and driver community
 
 See something missing from this list?  As PTL, I’m excited to work with our 
 community to refine this list for Juno.
 
 
 Other OpenStack Contributions
 --
 * Co-organizer of the Atlanta OpenStack Meetup
 * Member 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Samuel Bercovici]

Hi,

Although not a voting member, I would like to thank Mark for a phenomenal job 
on Neutron and LBaaS and would like to see him continue to lead Neutron forward.

Regards,
-Sam.


-Original Message-
From: Mark McClain [mailto:mark.mccl...@dreamhost.com] 
Sent: Friday, September 20, 2013 11:44 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] PTL Candidacy


Hi-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL.  Our team continued to grow during the Havana 
cycle and both existing and new contributors worked to deliver double the 
number of blueprints than the previous release.  Our vibrant ecosystem makes me 
excited for the future of Neutron and I would love to continue as the PTL.

Qualifications
---

I am a Neutron core developer with 13 years of commercial Python development 
experience.  During my career, I have developed and deployed network 
applications based on the same underlying libraries used throughout Neutron.  I 
started contributing to Neutron project during the Essex development cycle.  In 
Folsom, I was promoted to core and was the primary developer of the DHCP 
implementation and Neutron's network namespace library.  During Grizzly, I 
worked on the metadata service, database migrations, and LBaaS reference 
implementation.  

Havana Accomplishments


During the Havana cycle, I worked as a developer, core team member, and a 
technical lead.

- Planned and implemented the Quantum to Neutron name change.
- Most active reviewer on the Neutron team 
(http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt)
- Organized the Networking track at the Havana Design Summit.
- Led bug triaging and sub-team assignment.
- Interfaced with vendors new to Neutron and helped in the integration of their 
plugins.
- Assisted members of the community to further their understanding of Neutron 
and improve Python development best practices.
- Promoted Neutron by delivering presentations at conferences and regional meet 
ups worldwide.


Icehouse
-

During the Icehouse development cycle, I'd like to see the team focus on:

- Continuing to grow the community of contributors and code reviewers.
- Improving documentation for both deployers and developers.
- Build upon the services added in Havana to extend and improve load balancing, 
firewalling, and VPN.
- Integrating plugins from vendors new to the community including FWaaS, LBaaS, 
ML2, VPNaaS plugins/drivers.
- More efficient Neutron system testing and gating including full Tempest 
testing.
- Further work to ease deploying at scale.
- Refactoring the API layer to leverage a common WSGI framework as other 
OpenStack projects.
- Improving database resource modeling and extension management.
- Unified network service management framework. 
- Continued support of the Horizon team to assist with Neutron integration.
- Defined migration path from nova-network to Quantum.

I'd love the opportunity to continue as the PTL and work with the Neutron team 
to fill in the gaps during the design summit in Hong Kong.

Thanks,
mark




___
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] [Neutron] PTL Candidacy

[Mark McClain]

Hi-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL.  Our team continued to grow during the Havana 
cycle and both existing and new contributors worked to deliver double the 
number of blueprints than the previous release.  Our vibrant ecosystem makes me 
excited for the future of Neutron and I would love to continue as the PTL.

Qualifications
---

I am a Neutron core developer with 13 years of commercial Python development 
experience.  During my career, I have developed and deployed network 
applications based on the same underlying libraries used throughout Neutron.  I 
started contributing to Neutron project during the Essex development cycle.  In 
Folsom, I was promoted to core and was the primary developer of the DHCP 
implementation and Neutron's network namespace library.  During Grizzly, I 
worked on the metadata service, database migrations, and LBaaS reference 
implementation.  

Havana Accomplishments


During the Havana cycle, I worked as a developer, core team member, and a 
technical lead.

- Planned and implemented the Quantum to Neutron name change.
- Most active reviewer on the Neutron team 
(http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt)
- Organized the Networking track at the Havana Design Summit.
- Led bug triaging and sub-team assignment.
- Interfaced with vendors new to Neutron and helped in the integration of their 
plugins.
- Assisted members of the community to further their understanding of Neutron 
and improve Python development best practices.
- Promoted Neutron by delivering presentations at conferences and regional meet 
ups worldwide.


Icehouse
-

During the Icehouse development cycle, I'd like to see the team focus on:

- Continuing to grow the community of contributors and code reviewers.
- Improving documentation for both deployers and developers.
- Build upon the services added in Havana to extend and improve load balancing, 
firewalling, and VPN.
- Integrating plugins from vendors new to the community including FWaaS, LBaaS, 
ML2, VPNaaS plugins/drivers.
- More efficient Neutron system testing and gating including full Tempest 
testing.
- Further work to ease deploying at scale.
- Refactoring the API layer to leverage a common WSGI framework as other 
OpenStack projects.
- Improving database resource modeling and extension management.
- Unified network service management framework. 
- Continued support of the Horizon team to assist with Neutron integration.
- Defined migration path from nova-network to Quantum.

I'd love the opportunity to continue as the PTL and work with the Neutron team 
to fill in the gaps during the design summit in Hong Kong.

Thanks,
mark




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

Re: [openstack-dev] [Neutron] PTL Candidacy

[Dan Wendlandt]

+1

Mark has done a phenomenal job as Neutron PTL


On Fri, Sep 20, 2013 at 1:44 PM, Mark McClain mark.mccl...@dreamhost.comwrote:


 Hi-

 I writing to announce my candidacy for the OpenStack Networking (Neutron)
 PTL.

 I am the current Neutron PTL.  Our team continued to grow during the
 Havana cycle and both existing and new contributors worked to deliver
 double the number of blueprints than the previous release.  Our vibrant
 ecosystem makes me excited for the future of Neutron and I would love to
 continue as the PTL.

 Qualifications
 ---

 I am a Neutron core developer with 13 years of commercial Python
 development experience.  During my career, I have developed and deployed
 network applications based on the same underlying libraries used throughout
 Neutron.  I started contributing to Neutron project during the Essex
 development cycle.  In Folsom, I was promoted to core and was the primary
 developer of the DHCP implementation and Neutron's network namespace
 library.  During Grizzly, I worked on the metadata service, database
 migrations, and LBaaS reference implementation.

 Havana Accomplishments
 

 During the Havana cycle, I worked as a developer, core team member, and a
 technical lead.

 - Planned and implemented the Quantum to Neutron name change.
 - Most active reviewer on the Neutron team (
 http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt)
 - Organized the Networking track at the Havana Design Summit.
 - Led bug triaging and sub-team assignment.
 - Interfaced with vendors new to Neutron and helped in the integration of
 their plugins.
 - Assisted members of the community to further their understanding of
 Neutron and improve Python development best practices.
 - Promoted Neutron by delivering presentations at conferences and regional
 meet ups worldwide.


 Icehouse
 -

 During the Icehouse development cycle, I'd like to see the team focus on:

 - Continuing to grow the community of contributors and code reviewers.
 - Improving documentation for both deployers and developers.
 - Build upon the services added in Havana to extend and improve load
 balancing, firewalling, and VPN.
 - Integrating plugins from vendors new to the community including FWaaS,
 LBaaS, ML2, VPNaaS plugins/drivers.
 - More efficient Neutron system testing and gating including full Tempest
 testing.
 - Further work to ease deploying at scale.
 - Refactoring the API layer to leverage a common WSGI framework as other
 OpenStack projects.
 - Improving database resource modeling and extension management.
 - Unified network service management framework.
 - Continued support of the Horizon team to assist with Neutron integration.
 - Defined migration path from nova-network to Quantum.

 I'd love the opportunity to continue as the PTL and work with the Neutron
 team to fill in the gaps during the design summit in Hong Kong.

 Thanks,
 mark




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




-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] PTL Candidacy

[Justin Hammond]

I agree. +1. Mark has been nothing but helpful to me and I have enjoyed all the 
chances I have had to work with him. Not sure if I can vote though.

From: Dan Wendlandt d...@nicira.commailto:d...@nicira.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Fri, 20 Sep 2013 18:03:44 -0700
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] PTL Candidacy

+1

Mark has done a phenomenal job as Neutron PTL


On Fri, Sep 20, 2013 at 1:44 PM, Mark McClain 
mark.mccl...@dreamhost.commailto:mark.mccl...@dreamhost.com wrote:

Hi-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL.  Our team continued to grow during the Havana 
cycle and both existing and new contributors worked to deliver double the 
number of blueprints than the previous release.  Our vibrant ecosystem makes me 
excited for the future of Neutron and I would love to continue as the PTL.

Qualifications
---

I am a Neutron core developer with 13 years of commercial Python development 
experience.  During my career, I have developed and deployed network 
applications based on the same underlying libraries used throughout Neutron.  I 
started contributing to Neutron project during the Essex development cycle.  In 
Folsom, I was promoted to core and was the primary developer of the DHCP 
implementation and Neutron's network namespace library.  During Grizzly, I 
worked on the metadata service, database migrations, and LBaaS reference 
implementation.

Havana Accomplishments


During the Havana cycle, I worked as a developer, core team member, and a 
technical lead.

- Planned and implemented the Quantum to Neutron name change.
- Most active reviewer on the Neutron team 
(http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt)
- Organized the Networking track at the Havana Design Summit.
- Led bug triaging and sub-team assignment.
- Interfaced with vendors new to Neutron and helped in the integration of their 
plugins.
- Assisted members of the community to further their understanding of Neutron 
and improve Python development best practices.
- Promoted Neutron by delivering presentations at conferences and regional meet 
ups worldwide.


Icehouse
-

During the Icehouse development cycle, I'd like to see the team focus on:

- Continuing to grow the community of contributors and code reviewers.
- Improving documentation for both deployers and developers.
- Build upon the services added in Havana to extend and improve load balancing, 
firewalling, and VPN.
- Integrating plugins from vendors new to the community including FWaaS, LBaaS, 
ML2, VPNaaS plugins/drivers.
- More efficient Neutron system testing and gating including full Tempest 
testing.
- Further work to ease deploying at scale.
- Refactoring the API layer to leverage a common WSGI framework as other 
OpenStack projects.
- Improving database resource modeling and extension management.
- Unified network service management framework.
- Continued support of the Horizon team to assist with Neutron integration.
- Defined migration path from nova-network to Quantum.

I'd love the opportunity to continue as the PTL and work with the Neutron team 
to fill in the gaps during the design summit in Hong Kong.

Thanks,
mark




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



--
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.comhttp://www.nicira.com
twitter: danwendlandt
~~~
___ 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