Open Stack

Very good summary, thanks for leading the PTG and neutron so well. :)


On Mon, Mar 12, 2018 at 11:25 PM fumihiko kakuma <kakuma at valinux.co.jp>
wrote:

> 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>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180313/70da12c2/attachment.html>