Hi All!
Following below is a high-level update of what was discussed during the PTG. 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 ton of discussions going on attached to this update. You can find the etherpad we used during the PTG here: https://etherpad.openstack.org/p/neutron-queens-ptg. You can also playback the conversations here: * Wednesday morning session: https://www.youtube.com/watch?v=58AyKXHkI-I * Wednesday afternoon session: https://www.youtube.com/watch?v=LPxydx5ypAE * Thursday morning session: https://www.youtube.com/watch?v=zSHIpkR9Jxg * Thursday afternoon Neutron / Nova x-project session: https://www.youtube.com/watch?v=kF5uat0MbuY * Thursday late afternoon session: https://www.youtube.com/watch? v=lJm8vIwxGec Documentation =========== * The documentation team has defined a new mission for itself: https://review.openstack.org/#/c/499556/. This means that the Neutron team has to create and maintain its own documentation. The documentation team will only provide tools and guidance. * Code patchsets must include documentation from now on, when applicable. This will be enforced by all code reviewers. As a consequence, we will not use the DocImpact tag anymore. We are updating the contributors guide accordingly: https://review.openstack.org/#/c/503710/ * Patches that impact the API must depend on a corresponding patch in neutron-lib that update api-ref * Boden has graciously accepted to be the liaison with the documentation team: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation * The release checklist has to be updated to include a step to insure there are no broken links in the docs * We need volunteers to move the archived configuration guide ( https://github.com/openstack/neutron/tree/master/doc/source/admin/archives) into the networking guide * Pike install guides need to be verified. We also need volunteers for this * The stable/pike document backport policy is to backport patches as they come, with the exception of API reference contributions, which must target the master branch of neutron-lib neutron-lib ======== * New callback payload adoption: we will treat the adoption of the new payload style objects as we have been with other lib impact changes. * Decoupling of DB related access for neutron-lib: recommendation was to move OVO fields definitions to neutron-lib, instead of the currently proposed approach (PoC https://review.openstack.org/#/c/476652) to extract specific objects methods from the different OVOs DevStack ===== * We have several patches that need the attention of DevStack core reviewers: https://review.openstack.org/#/q/status:open+topi c:new-neutron-devstack-in-gate * Miguel Lavalle to talk to DevStack team to get them to pay attention to these patches Common Classification Framework ========================== * The spec is: https://review.openstack.org/#/c/320439 * Making good progress towards releasing V1 during Queens * Message sent to the distribution list requesting feedback on protocols that should be supported: http://lists.openstack.org/pip ermail/openstack-dev/2017-August/121531.html * FWaaS, SFC and Dragonflow have shown interest in adopting CCF * Adding classifying based on neutron resources is being considered. A SFC PoC is going to be implemented CLI related topics ============= * With OSC resource attributes extensions must be added directly/statically to the sdk's resource and then consumed in the client, unlike the python-neutronclient, where that doesn’t require any client-side code changes. * As a consequence, we will not drop support for python-neutronclient until we achieve parity. * Boden Russel will follow up with a message to the mailing list to request the current status of support for attribute extensions in OSC * Akihiro Motoki will discuss the future of LBaaS CLI with octavia team * yushiro will discuss with the FWaaS team the future of the v1 CLI/API Pike backlog plans ============== * Security group logging. Remaining 4 functionality patches are ready for review and targeted to merge by Q-1: - Logging agent extension: https://review.openstack.org/396104 - RPC stuff and driver api: https://review.openstack.org/468265 - OVS firewall logging driver: https://review.openstack.org/468281 - CLI: https://review.openstack.org/#/c/409819/ * Security group logging: testing and documentation patches are targeted to merge in Q-2 - API and scenario test: https://review.openstack.org/#/c/482886/ - Functional test: https://review.openstack.org/#/c/418862/ - Documentation: https://review.openstack.org/#/c/480117/ * Trevor McCasland will conclude the implementation of QinQ network type driver * Boden Russell will re-propose network resource diagnostics for Queens: https://review.openstack.org/#/c/308973/ * Implementation of “Provide Port Binding Information for Nova Live Migration” (http://specs.openstack.org/openstack/neutron-specs/specs/ pike/portbinding_information_for_nova.html) will be continued by Miguel Lavalle (see also the Nova / Neutron section below) * Kevin Benton will follow up with Ann Taraday to find out the current status of the DB engine façade adoption * Akihiro Motoki to create an etherpad or similar document to track the status of api reference documents in neutron-lib * Slawek Kaplonski to propose a patch to implement the Quota details client. * FWaaS update: - Priority during Queens is to finish and stabilize V2 API and provide support to L2. Support from L3 - L7 will be implemented in future releases - The second priority during Queens is the implementation of API and scenario tests, with the aim of encouraging distros to ship and support FWaaS * Enhancing security groups with a 'deny' attribute - Pros: unlocking relatively quickly the implementation of some use cases - Cons: implementing competing ways to achieve the same functionality in security groups and FWaaS V2 - After considering pros and cons, consensus was reached to focus in Queens on stabilizing FWaaS V2 Testing ===== * The CI and L3 sub-teams will cooperate on making the DVR-HA multinode job voting to achieve overarching coverage - The L3 sub-team will add a regular CI topic to their weekly meeting agenda, to make sure progress is achieved on this subject * We will split the Tempest plugin in Neutron into a different branch-less repo, according to the community goal. This is achieved in the following patches: - https://review.openstack.org/#/c/502222 - https://review.openstack.org/#/c/502224 * In trunk fullstack testing, we run multiple ovs-agents in a single node. As a consequence, when a port is removed from a trunk bridge all the agents will attempt to clean resources from the given trunk bridge - Armando Migliaccio will propose a temporary fix to associate an agent prefix to the trunk bridge - In parallel, Jakub Libosvar will continue working on a more permanent solution based on OVS sandboxing API === * There is a TC defined community goal to move default policy definitions from file-based maintenance to registering them in code ( https://governance.openstack.org/tc/goals/queens/policy-in-code.html) - We already have a patch to implement this goal: https://review.openstack.org/#/c/434997. Miguel Lavalle will follow it up * Kevin Benton to look at Glance / Keystone for ENV variable lookup of configuration files and will propose a patch Reference implementation topics ======================== * OVS agent - ovsdb_interface option will be deprecated in Queens, with the goal of removing the CLI driver in Rocky: https://review.openstack.org/#/c/503070 - Removing of_interface option and ovs-ofctl related code in Queens: https://review.openstack.org/#/c/503076 - We need a mechanism to migrate to OVS Firewall. Kevin Benton agreed to file a bug to add logic to the L2 agent to drop iptables on filtering bridges when an operator switches to OVS Firewall * Adoption of os-vif in Neutron (https://github.com/openstack/os-vif) - The goal is to replace the agent Linux interface module with calls to os-vif so VIF plugging and un-plugging logic doesn't have to be duplicated in Neutron ( https://bugs.launchpad.net/neutron/+bug/1707156) - Rodolfo Alonso is working on a PoC: https://review.openstack.org/# /q/status:open+branch:master+topic:osvif_migration - Related to this is the the existence of code to create interface in a IVS (Indigo Virtual Switch) bridge. Kevin Benton indicated that this code can be removed (https://github.com/openstack/neutron/blob/master/neutron/ag ent/linux/interface.py#L410) * David Shaughnessy is working on a PoC of a DVR OpenFlow implementation - We agreed to continue this PoC under the assumption that we will stabilize the current DVR before attempting to merge any of the new code - The proposed code in the PoC provides its own classes for the new type of router, so it is well isolated from the current in tree code. We intend to keep it this way - We will focus on fullstack testing for this new feature, so we don't complicate the current suite of DVR tests with more Tempest jobs. * Kevin Benton will not have time to work on replacing l2_pop with information in the data model - We have a patch that never merged to setup arp_responder in the integration bridge: https://review.openstack.org/#/c/248177 - The challenge is to figure out how to store the relevant information in the data model and to come up with a safe migration plan - Kevin agreed to help review the code if we get someone to continue this work * Linuxbridge - To fix the Linuxbridge multinode job (https://bugs.launchpad.net/ne utron/+bug/1683256), Kevin Benton will follow up with infra to set up tunnels across the compute nodes so that multicast in the underlay does not have to be assumed (devstack gate) - Trunk scenario needs to be fixed to make the Linuxbridge scenario job stable L3 flavors ======= * The assignment of a service provider to a router is implemented as a callback subscribed to router create pre-commit event. - This mechanism can be racy. - Isaku Yamahata and Manjeet Singh Bhatia have volunteered to work on fixing the events systems, with Armando Migliaccio and Takashi Yamamoto reviewing the code. * Midonet supports IPv6 floating IPs but the reference implementation does not - If we lift the constraint in l3_db then users can create floating IPs with v6 addrs but they will never be able to associate them unless midonet or another l3 backend that supports them is used - A decision was left pending on whether to support IPv6 floating IPs * Currently we don't have a way to manage the compatibility or lack thereof between L3 flavors and ML2 drivers - Armando Migliaccio will propose an approach to handle this Floating IPs for routed networks ======================= * A spec is up for review: https://review.openstack.org/#/c/486450/. It incorporates the feedback of one large operator (GoDaddy). Other operators are encouraged to review and provide feedback * The team decided to split this spec in two. The first one will focus on adding a 'service_type' attribute to floating IPs, which may be useful for other use cases.The second one will focus on the changes needed to BGP Dynamic Routing to implement floating IPs for routed networks * This is targeted for Queens Nova / Neutron integration =================== * Neutron port binding extension for live migration - This extension (spec:https://specs.openstack. org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html) will provide an API to create bindings in multiple hosts for a port. Only one of those bindings can be active at a time - When this extension is available, Nova will use it to bind ports in the destination host during the pre_live_migration stage of an instance migration. The destination host binding will be set to active during the post_live_migration stage. This will minimize the network down time during the migration. - Previous work to wire L3 during the pre_live_migration stage will be updated accordingly: https://review.openstack.org/#/c/275073/, https://review.openstack.org/#/c/275420/, https://review.openstack.org/# /c/260738/ - This work will proceed in parallel with the implementation of os-vif object negotiation and could be merged at the end of the cycle - This work will also proceed in parallel with the move in Nova of the port orchestration to the conductor ( https://review.openstack.org/#/c/375580/) - Sean Mooney and Rodolfo Alonso will work on the Nova side. Miguel Lavalle will work on the Neutron side * Using os-vif for port binding negotiation. Sean Mooney and Rodolfo Alonso already have PoC code. They will continue the work during Queens * Bandwidth-based scheduling - Some work on the Neutron side has already started along the lines of the following spec: https://specs.openstack.org/openstack/neutron-specs/specs/ba cklog/pike/strict-minimum-bandwidth-support.html. Rodolfo Alonso, Slawek Kaplonski and Miguel Lavalle have committed to continue implementation in Queens - This feature has a strong dependency on the implementation of nested resource providers in the Placement service, which is expected to complete in Q-1 Neutron to Neutron connectivity with BGPVPN ================================= * Thomas Morin proposed to use BGPVPN to define a router in an OpenStack that has an 'alias router' in a remote OpenStack (this has to be done symmetrically in both OpenStacks). VPN identifiers are exchanged to establish the connection and orchestration is not required. - Federation is not necessary. All that is required is for each OpenStack to have an admin user from the other side configured in order to ascertain the existence of the alias - It was agreed that the next step will be to write a specification Community related topics ================== * The team brainstormed on steps to take to develop new core reviewers. The following actions were agreed upon: - Establish a mentoring process, whereby people interested in progressing to core will be paired with current team members. This will require identifying those people interested on being mentored as well as people interested in mentoring - Establish deep dive sessions to train people on deep technical aspects of the different components of Neutron - We are going to clean-up on-boarding documentation - We are going to respin and maintain low-hanging-fruit list to address concerns over fruits being not very low hanging - We will identify areas where contributors are needed, using as a starting point https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#core-review-hierarchy * Bug management issues. Over the past few months, we have had difficulty getting weekly volunteers to triage bugs - We decided to define a fixed rotation among the team members. Miguel Lavalle will make a proposal - We will follow up on implementing an IRC bot to notify in the Neutron channel the filing of new bugs
__________________________________________________________________________ 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
