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 <[email protected]> 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 <[email protected]> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
