Open Stack

Hi Miguel,

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

networking-ofagent has been removed in the Newton release.
So it will not be necessary to support it as part of neutron-lib updates.

Thanks
kakuma.


On Mon, 12 Mar 2018 13:45:27 -0500
Miguel Lavalle <miguel at mlavalle.com> wrote:

> 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

-- 
fumihiko kakuma <kakuma at valinux.co.jp>