Open Stack

Hi All!

First of all, I want to thank you the team for the productive week we had
in Dublin. Following below is a high level summary of the discussions we
had. If there is something I left out, please reply to this email thread to
add it. However, if you want to continue the discussion on any of the
individual points summarized below, please start a new thread, so we don't
have a lot of conversations going on attached to this update.

You can find the etherpad we used during the PTG meetings here:
https://etherpad.openstack.org/p/neutron-ptg-rocky


Retrospective
==========

* The team missed one community goal in the Pike cycle (
https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and
one in the Queens cycle (https://governance.openstack.
org/tc/goals/queens/policy-in-code.html)

   - Akihiro Motoki will work on https://governance.openstack.o
rg/tc/goals/queens/policy-in-code.html during Rocky

  - We need volunteers to complete https://governance.op
enstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and the two new goals
for the Rocky cycle: https://governance.openstack.o
rg/tc/goals/rocky/enable-mutable-configuration.html and
https://governance.openstack.org/tc/goals/rocky/mox_removal.html. Akihiro
Motoki will lead the effort for mox removal

  - We decided to add a section to our weekly meeting agenda where we are
going to track the progress towards catching up with the community goals
during the Rocky cycle

* As part of the neutron-lib effort, we have found networking projects that
are very inactive. Examples are networking-brocade (no updates since May of
2016) and networking-ofagent (no updates since March of 2017). Miguel
Lavalle will contact these projects leads to ascertain their situation. If
they are indeed inactive, we will not support them as part of neutron-lib
updates and will also try to remove them from code search

* We will continue our efforts to recruit new contributors and develop core
reviewers. During the conversation on this topic, Nikolai de Figueiredo and
Pawel Suder announced that they will become active in Neutron. Both of
them, along with Hongbin Lu, indicated that are interested in working
towards becoming core reviewers.

* The team went through the blueprints in the backlog. Here is the status
for those blueprints that are not discussed in other sections of this
summary:

   - Adopt oslo.versionedobjects for database interactions. This is a
continuing effort. The contact is Ihar Hrachyshka  (ihrachys). Contributors
are wanted. There is a weekly meeting led by Ihar where this topic is
covered: http://eavesdrop.openstack.org/#Neutron_Upgrades_Meeting

   - Enable adoption of an existing subnet into a subnetpool. The final
patch in the series to implement this feature is:
https://review.openstack.org/#/c/348080. Pawel Suder will drive this patch
to completion

   - Neutron in-tree API reference (https://blueprints.launchpad.
net/neutron/+spec/neutron-in-tree-api-ref). There are two remaining TODOs
to complete this blueprint: https://bugs.launchpad.net/neutron/+bug/1752274
and https://bugs.launchpad.net/neutron/+bug/1752275. We need volunteers for
these two work items

   - Add TCP/UDP port forwarding extension to L3. The spec was merged
recently: https://specs.openstack.org/openstack/neutron-specs/specs/qu
eens/port-forwarding.html. Implementation effort is in progress:
https://review.openstack.org/#/c/533850/ and  https://review.openstack.org/#
/c/535647/

   - Pure Python driven Linux network configuration (
https://bugs.launchpad.net/neutron/+bug/1492714). This effort has been
going on for several cycles gradually adopting pyroute2. Slawek Kaplonski
is continuing it with https://review.openstack.org/#/c/545355 and
https://review.openstack.org/#/c/548267


Port behind port API proposal
======================

* Omer Anson proposed to extend the Trunk Port API to generalize the
support for port behind port use cases such as containers nested as
MACVLANs within a VM or HA proxy port behind amphora VM port:
https://bugs.launchpad.net/bugs/1730845

   - After discussing the proposed use cases, the agreement was to develop
a specification making sure input is provided by the Kuryr and Octavia teams


ML2 and Mechanism drivers
=====================

* Hongbin Lu presented a proposal (https://bugs.launchpad.net/ne
utron/+bug/1722720) to add a new value "auto" to the port attribute
admin_state_up.

   - This is to support SR-IOV ports, where admin_state_up == "auto" would
mean that the VF link state follows that of the PF. This may be useful when
VMs use the link as a trigger for its own HA mechanism
   - The agreement was not to overload the admin_state_up attribute with
more values, since it reflects the desired administrative state of the port
and add a new attribute for the intended purpose

* Zhang Yanxian presented a specification (https://review.openstack.org/
506066) to support SR-IOV bonds whereby a Neutron port is associated with
two VFs in separate PFs. This is useful in NFV scenarios, where link
redundancy is necessary.

   - Nikolai de Figueiredo agreed to help to drive this effort forward,
starting with the specification both in the Neutron and the Nova sides
   - Sam Betts indicated this type of bond is also of interest for Ironic.
He requested to be kept in the loop

* Ruijing Guo proposed to support VLAN transparency in Neutron OVS agent.

   - There is a previous incomplete effort to provide this support:
https://bugs.launchpad.net/neutron/+bug/1705719. Patches are here:
https://review.openstack.org/#/q/project:openstack/neutron+topic:bug/1705719
   - Agreement was for Ruijing to look at the existing patches to re-start
the effort. Thomas Morin may provide help for this
   - While on this topic, the conversation temporarily forked to the use of
registers instead of ovsdb port tags in L2 agent br-int and possibly remove
br-tun. Thomas Morin committed to draft a RFE for this.

* Mike Kolesnik, Omer Anson, Irena Berezovsky, Takashi Yamamoto, Lucas
Alvares, Ricardo Noriega, Miguel Ajo, Isaku Yamahata presented the proposal
to implement a common mechanism to achieve synchronization between
Neutron's DB and the DBs of sub-projects / SDN frameworks

   - Currently each sub-project / SDN framework has its own solution for
this problem. The group thinks that a common solution can be achieved
   - The agreement was to create a specification where the common solution
can be fleshed out
   - The synchronization mechanism will exist in Neutron

* Mike Kolesnik (networking-odl) requested feedback from members of other
Neutron sub-projects about the value of inheriting ML2 Neutron's unit tests
to get "free testing" for mechanism drivers

   - The conclusion was that there is no value in that practice for the
sub-rpojects
   - Sam Betts and Miguel Lavalle will explore moving unit tests utils to
neutron-lib to enable subprojects to create their own base classes
   - Mike Kolesnik will document a guideline for sub-projects not to
inherit unit tests from Neutron


API topics
========

* Isaku Yamahata presented a proposal of a new API for cloud admins to
retrieve the physical networks configured in compute hosts

   - This information is currently stored in configuration files. In
agent-less environments it is difficult to retrieve
   - The agreement was to extend the agent API to expose the physnet as a
standard attribute. This will be fed by a pseudo-agent

* Isaku Yamahata presented a proposal of a new API to report mechanism
drivers health

   - The overall idea is to report mechanism driver status, similar to the
agents API which reports agent health. In the case of mechanism drivers
API, it would report connectivity to backend SDN controller or  MQ server
and report its health/config periodically
   - Thomas Morin pointed out that this is relevant not only for ML2
mechanism drivers but also for all drivers of different services
   - The agreement was to start with a specification where we scope the
proposal into something manageable for implementation

* Yushiro Furukawa proposed to add support of 'snat' as a loggable resource
type: https://bugs.launchpad.net/neutron/+bug/1752290

   - The agreement was to implement it in Rocky
   - Brian Haley agreed to be the approver

* Hongbin Lu indicated that If users provide different kinds of invalid
query parameters, the behavior of the Neutron API looks unpredictable (
https://bugs.launchpad.net/neutron/+bug/1749820)

   - The proposal is to improve the predictability of the Neutron API by
handling invalid query parameters consistently
   - The proposal was accepted. It will need to provide API discoverability
when behavior changes on filter parameter validation
   - It was also recommended to discuss this with the API SIG to get their
guidance. The discussion already started in the mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128021.html


Openflow Manager and Common Classification Framework
==========================================

* The Openflow manager implementation needs reviews to continue making
progress

   - The approved spec is here: https://specs.openstack.org/op
enstack/neutron-specs/specs/backlog/pike/l2-extension-ovs-fl
ow-management.html
   - The code is here: https://review.openstack.org/323963
   - Thomas Morin, David Shaughnessy and Miguel Lavalle discussed and
reviewed the implementation during the last day of the PTG. The result of
that conversation was reflected in the patch. Thomas and Miguel committed
to continue reviewing the patch

* The Common Classification Framework (https://specs.openstack.org/o
penstack/neutron-specs/specs/pike/common-classification-framework.html)
needs to be adopted by its potential consumers: QoS, SFC, FWaaS

   - David Shaughnessy and Miguel Lavalle met with Slawek Kaplonski over
IRC the last day of the PTG  (http://eavesdrop.openstack.or
g/irclogs/%23openstack-neutron/%23openstack-neutron.2018-03-
02.log.html#t2018-03-02T12:00:34) to discuss the adoption of the framework
in QoS code. The agreement was to have a PoC for the DSCP marking rule,
since it uses OpenFlow and wouldn't involve big backend changes

   - David Shaughnessy and Yushiro Furukawa are going to meet to discuss
adoption of the framework in FWaaS


Neutron to Neutron interconnection
=========================

* Thomas Morin walked the team through an overview of his proposal (
https://review.openstack.org/#/c/545826) for Neutron to Neutron
interconnection, whereby the following requirements are satisfied:

   - Interconnection is consumable on-demand, without admin intervention
   - Have network isolation and allow the use of private IP addressing end
to end
   - Avoid the overhead of packet encryption

* Feedback was positive and the agreement is to continue developing and
reviewing the specification


L3 and L3 flavors
============

* Isaku Yamahata shared with the team that the implementation of routers
using the L3 flavors framework gives rise to the need of specifying the
order in which callbacks are executed in response to events

   - Over the past couple of months several alternatives have been
considered: callback cascading among resources, SQLAlchemy events,
assigning priorities to callbacks responding to the same event
   - The agreement was an approach based on assigning a priority structure
to callbacks in neutron-lib: https://review.openstack.org/#/c/541766

* Isaku Yamahata shared with the team the progress made with the PoC for an
Openflow based DVR: https://review.openstack.org/#/c/472289/ and
https://review.openstack.org/#/c/528336/

   - There was a discussion on whether we need to ask the OVS community to
do ipv6 modification to support this PoC. The conclusion was that the
feature already exists
   - There was also an agreement for David Chou add Tempest testing for the
scenario of mixed agents


neutron-lib
========

* The team reviewed two neutron-lib specs, providing feedback through
Gerrit:

   - A spec to rehome db api and utils into neutron-lib:
https://review.openstack.org/#/c/473531.
   - A spec to decouple neutron db models and ovo for neutron-lib:
https://review.openstack.org/#/c/509564/. There is agreement from Ihar
Ihrachys that OVO base classes should go into neutron-lib. But he asked not
to move yet neutron.objects.db.api since it's still in flux

* Manjeet Singh Bhatia proposed making payload consistent for all the
callbacks so all the operations of an object get same type of payload. (
https://bugs.launchpad.net/neutron/+bug/1747747)

   - The agreement was for Manjeet to document all the instances in the
code where this is happening so he and others can work on making the
payloads consistent


Proposal to migrate neutronclient python bindings to OpenStack SDK
==================================================

* Akihiro Motoki proposed to change the first priority of neutron-related
 python binding to OpenStack SDK rather than neutronclient python bindings,
given that OpenStack SDK became official in Queens (
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127726.html
)

   - The proposal is to implement all Neutron features in OpenStack SDK as
the first citizen and the neutronclient OSC plugin consumes corresponding
OpenStack SDK APIs
   - New features should be supported in OpenStack SDK and
OSC/neutronclient OSC plugin as the first priority
   - If a new feature depends on neutronclient python bindings, it can be
implemented in neutornclient python bindings first and they are ported as
part of existing feature transition
   - Existing features only supported in neutronclient python bindings are
ported into OpenStack SDK, and neutronclient OSC plugin will consume them
once they are implemented in OpenStack SDK
   - There is no plan to drop the neutronclient python bindings since not a
small number of projects consumes it. It will be maintained as-is
   - Projects like Nova that consume a small set of neutron features can
continue using neutronclient python bindings. Projects like Horizon or Heat
that would like to support a wide range of features might be better off
switching to OpenStack SDK
   - Proposal was accepted


Cross project planning with Nova
========================

* Minimum bandwidth support in the Nova scheduler. The summary of the
outcome of the discussion and further work done after the PTG is the
following:

   - Minimum bandwidth support guarantees a port minimum bandwidth. Strict
minimum bandwidth support requires cooperation with the Nova scheduler, to
avoid physical interfaces bandwidth overcommitment
   - Neutron will create in each host networking RPs (Resource Providers)
under the compute RP with proper traits and then will report resource
inventories based on the discovered and / or configured resource inventory
in the host
   - The hostname will be used by Neutron to find the compute RP created by
Nova for the compute host. This convention can create ambiguity in
deployments with multiple cells, where hostnames may not be unique. However
this problem is not exclusive to this effort, so its solution will be
considered out of scope
   - Two new standard Resource Classes will be defined to represent the
bandwidth in each direction, named as `NET_BANDWIDTH_INGRESS_BITS_SEC` and
`NET_BANDWIDTH_EGRESS_BITS_SEC
   - New traits will be defined to distinguish a network back-end agent:
`NET_AGENT_SRIOV`, `NET_AGENT_OVS`. Also new traits will be used to
indicate which physical network a given Network RP is connected to
   - Neutron will express a port's bandwidth needs through the port API in
a new attribute named "resource_request" that will include ingress
bandwidth, egress bandwidth, the physical net and the agent type
   - The first implementation of this feature will support server create
with pre-created Neutron ports having QoS policy with minimum bandwidth
rules. Server create with networks having QoS policy minimum bandwidth rule
will be out of scope of the first implementation, because currently, in
this case, the corresponding port creations happen after the scheduling
decision has been made
   - For the first implementation, Neutron should reject a QoS minimum
bandwidth policy rule created on a bound port
   - The following cases don't involve any interaction in Nova and as a
consequence, Neutron will have to adjust the resource allocations: QoS
policy rule bandwidth amount change on a bound port and QoS aware sub port
create under a bound parent port
   - For more detailed discussion, please go to the following specs:
https://review.openstack.org/#/c/502306 and https://review.openstack.org/#
/c/508149

* Provide Port Binding Information for Nova Live Migration (
https://specs.openstack.org/openstack/neutron-specs/specs/
backlog/pike/portbinding_information_for_nova.html and
https://specs.openstack.org/openstack/nova-specs/specs/
queens/approved/neutron-new-port-binding-api.html).

   - There was no discussion around this topic
   - There was only an update to both teams about the solid progress that
has been made on both sides: https://review.openstack.org/#/c/414251/ and
https://review.openstack.org/#/q/status:open+project:
openstack/nova+branch:master+topic:bp/neutron-new-port-binding-api
   - The plan is to finish this in Rocky

* NUMA aware switches https://review.openstack.org/#/c/541290/

   - The agreement on this topic was to do this during Rocky entirely in
Nova using a config option which is a list of JSON blobs

* Miguel Lavalle and Hongbin Lu proposed to add device_id of the associated
port to the floating IP resource

   - The use case is to allow Nova to filter instances by floating IPs
   - The agreement was that this would be adding an entirely new contract
to Nova with new query parameters. This will not be implemented in Nova,
especially since the use case can already be fulfilled by making 3 API
calls in a client: find floating IP via filter (Neutron), use that to
filter port to get the device_id (Neutron), use that to get the server
(Nova)


Team photos
=========

* Thanks to Kendall Nelson, the official PTG team photos can be found here:
https://www.dropbox.com/sh/dtei3ovfi7z74vo/AABT7UR5el6iXRx5WihkbOB3a/
Neutron?dl=0

* Thanks to Nikolai de Figueiredo for sharing with us pictures of our team
dinner. Please find a couple of them attached to this message
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180312/ffba348e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Neutron dinner Dublin 1.jpg
Type: image/jpeg
Size: 4024788 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180312/ffba348e/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Neutron dinner Dublin 2.jpg
Type: image/jpeg
Size: 3106795 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180312/ffba348e/attachment-0003.jpg>