<div dir="ltr">Hi All!<br>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal">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.<span></span></p><p class="MsoNormal"><br></p>
<p class="MsoNormal">You can find the etherpad we used during the PTG here: <a href="https://etherpad.openstack.org/p/neutron-queens-ptg" target="_blank">https://etherpad.openstack.org<wbr>/p/neutron-queens-ptg</a>.
You can also playback the conversations here:<span></span></p><p class="MsoNormal"><br></p>
<p class="MsoNormal">* Wednesday morning session: <a href="https://www.youtube.com/watch?v=58AyKXHkI-I" target="_blank"><span style="font-size:9pt;line-height:107%;font-family:Arial,sans-serif">https://www.youtube.com/watch?<wbr>v=58AyKXHkI-I</span></a><span></span></p>
<p class="MsoNormal">* Wednesday afternoon session: <a href="https://www.youtube.com/watch?v=LPxydx5ypAE" target="_blank">https://www.youtube.com/watch?<wbr>v=LPxydx5ypAE</a><span></span></p>
<p class="MsoNormal">* Thursday morning session: <a href="https://www.youtube.com/watch?v=zSHIpkR9Jxg" target="_blank">https://www.youtube.com/watch?<wbr>v=zSHIpkR9Jxg</a><span></span></p>
<p class="MsoNormal">* Thursday afternoon Neutron / Nova x-project session: <a href="https://www.youtube.com/watch?v=kF5uat0MbuY" target="_blank">https://www.youtube.com/watch?<wbr>v=kF5uat0MbuY</a><span></span></p>
<p class="MsoNormal">* Thursday late afternoon session: <a href="https://www.youtube.com/watch?v=lJm8vIwxGec" target="_blank">https://www.youtube.com/watch?<wbr>v=lJm8vIwxGec</a><span></span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal">Documentation<span></span></p>
<p class="MsoNormal">===========<span></span></p>
<p class="MsoNormal">* The documentation team has defined a new mission for
itself: <a href="https://review.openstack.org/#/c/499556/" target="_blank">https://review.openstack.org/#<wbr>/c/499556/</a>. This means that the Neutron
team has to create and maintain its own documentation. The documentation team
will only provide tools and guidance.<span></span></p>
<p class="MsoNormal">* 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: <a href="https://review.openstack.org/#/c/503710/" target="_blank">https://review.openstack.org/#<wbr>/c/503710/</a><span></span></p><p class="MsoNormal">* Patches that impact the API must depend on a corresponding patch in neutron-lib that update api-ref </p>
<p class="MsoNormal">* Boden has graciously accepted to be the liaison with the
documentation team: <a href="https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation" target="_blank">https://wiki.openstack.org/wik<wbr>i/CrossProjectLiaisons#Documen<wbr>tation</a></p>
<p class="MsoNormal">* The release checklist has to be updated to include a step
to insure there are no broken links in the docs<span></span></p>
<p class="MsoNormal">* We need volunteers to move the archived
configuration guide
(<a href="https://github.com/openstack/neutron/tree/master/doc/source/admin/archives">https://github.com/openstack/neutron/tree/master/doc/source/admin/archives</a>) into the
networking guide<span></span></p>
<p class="MsoNormal">* Pike install guides need to be verified. We also need volunteers for this<span></span></p>
<p class="MsoNormal">* 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</p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal">neutron-lib<span></span></p>
<p class="MsoNormal">========<span></span></p>
<p class="MsoNormal">* New callback payload adoption: <span></span><span style="font-size:12.8px">we will treat the adoption of the new payload style objects as we </span><span style="font-size:12.8px">have been with other lib impact changes.</span></p><p class="MsoNormal">*
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 <a href="https://review.openstack.org/#/c/476652" target="_blank">https://review.openstack.org/#<wbr>/c/476652</a>) to extract specific objects methods from the different OVOs<span></span></p><p class="MsoNormal"><br></p><p class="MsoNormal">DevStack</p><p class="MsoNormal">=====</p><p class="MsoNormal">* We have several patches that need the attention of DevStack core reviewers: <a href="https://review.openstack.org/#/q/status:open+topic:new-neutron-devstack-in-gate" target="_blank">https://review.open<wbr>stack.org/#/q/status:open+topi<wbr>c:new-neutron-devstack-in-gate</a></p><p class="MsoNormal">* Miguel Lavalle to talk to DevStack team to get them to pay attention to these patches</p><p class="MsoNormal"><br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">Common Classification
Framework<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">==========================</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">* The spec is: <a href="https://review.openstack.org/#/c/320439" target="_blank">https://review.openstack.org/#<wbr>/c/320439</a><br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Making good progress
towards releasing V1 during Queens<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Message sent to the
distribution list requesting feedback on protocols that should be supported: <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/121531.html" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2017-Augu<wbr>st/121531.html</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* FWaaS, SFC and
Dragonflow have shown interest in adopting CCF<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Adding classifying
based on neutron resources is being considered. A SFC PoC is going to be
implemented <span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span> </span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">CLI related topics<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">=============<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* With OSC resource
attributes extensions must be added directly/statically </span><span style="font-family:Arial,sans-serif">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.</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* As a consequence, we
will not drop support for python-neutronclient until we achieve parity.<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">*
Boden Russel will follow up with a message to the mailing list to
request the current status of support for attribute extensions in OSC<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Akihiro Motoki will discuss
the future of LBaaS CLI with octavia team<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* yushiro will discuss with the FWaaS team the future of the v1 CLI/API<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span> </span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">Pike backlog plans<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">==============<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Security group
logging. Remaining 4 functionality patches are ready for review and targeted to
merge by Q-1: <span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Logging agent extension: <a href="https://review.openstack.org/396104" target="_blank">https://review.openstack.org/3<wbr>96104</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- RPC stuff and driver api: <a href="https://review.openstack.org/468265" target="_blank">https://review.openstack.org/4<wbr>68265</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- OVS firewall logging driver: <a href="https://review.openstack.org/468281" target="_blank">https://review.openstack.org/4<wbr>68281</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- CLI: <a href="https://review.openstack.org/#/c/409819/" target="_blank">https://review.openstack.org/#<wbr>/c/409819/</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Security group
logging: testing and documentation patches are targeted to merge in
Q-2<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- API and scenario test: <a href="https://review.openstack.org/#/c/482886/" target="_blank">https://review.openstack.org/#<wbr>/c/482886/</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Functional test: <a href="https://review.openstack.org/#/c/418862/" target="_blank">https://review.openstack.org/#<wbr>/c/418862/</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Documentation: <a href="https://review.openstack.org/#/c/480117/" target="_blank">https://review.openstack.org/#<wbr>/c/480117/</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Trevor McCasland
will conclude the implementation of QinQ network type driver<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Boden Russell will
re-propose network resource diagnostics for Queens: <a href="https://review.openstack.org/#/c/308973/" target="_blank">https://review.openstack.org/#<wbr>/c/308973/</a><span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Implementation of “Provide
Port Binding Information for Nova Live Migration” (<a href="http://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html" target="_blank">http://specs.openstack.org/<wbr>openstack/neutron-specs/specs/<wbr>pike/portbinding_information_f<wbr>or_nova.html</a>)
will be continued by Miguel Lavalle (see also the Nova / Neutron section below)<span></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Kevin Benton will
follow up with Ann Taraday to find </span><span style="font-family:Arial,sans-serif">out </span><span style="font-family:Arial,sans-serif">the current status of the DB engine façade adoption<span></span></span></p><p class="MsoNormal">
</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Akihiro Motoki to
create an etherpad or similar document to track the status of api reference
documents in neutron-lib<span style="font-size:12pt"></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* </span><font face="Arial, sans-serif">Slawek Kaplonski to propose a patch to implement the </font><span style="font-family:Arial,sans-serif">Quota details client.</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* FWaaS update:</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
The second priority during Queens is the implementation of API and
scenario tests, with the aim of encouraging distros to ship and support
FWaaS</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Enhancing security groups with a 'deny' attribute</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Pros: unlocking relatively quickly the implementation of some use cases</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Cons: implementing competing ways to achieve the same functionality in security groups and FWaaS V2</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- After considering pros and cons, consensus was reached to focus in Queens on stabilizing FWaaS V2</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">Testing</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">=====</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* The CI and L3 sub-teams will cooperate on making the DVR-HA multinode job voting to achieve overarching coverage<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- The L3 sub-team will add a regular CI topic to their weekly meeting agenda, to make sure progress is achieved on this subject</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">*
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:</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- <a href="https://review.openstack.org/#/c/502222" target="_blank">https://review.openstack.org/#<wbr>/c/502222</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- <a href="https://review.openstack.org/#/c/502224" target="_blank">https://review.openstack.org/#<wbr>/c/502224</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">*
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</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Armando Migliaccio will propose a temporary fix to associate an agent prefix to the trunk bridge</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- In parallel, Jakub Libosvar will continue working on a more permanent solution based on OVS sandboxing</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">API</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">===</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">*
There is a TC defined community goal to move default policy definitions
from file-based maintenance to registering them in code (<a href="https://governance.openstack.org/tc/goals/queens/policy-in-code.html" target="_blank">https://governance.openstack.<wbr>org/tc/goals/queens/policy-in-<wbr>code.html</a>)<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- We already have a patch to implement this goal: <a href="https://review.openstack.org/#/c/434997" target="_blank">https://review.openstack.org/#<wbr>/c/434997</a>. Miguel Lavalle will follow it up<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Kevin Benton to look at Glance / Keystone for ENV variable lookup of configuration files and will propose a patch</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">Reference implementation topics</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">========================</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* OVS agent<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- ovsdb_interface option will be deprecated in Queens, with the goal of removing the CLI driver in Rocky: <a href="https://review.openstack.org/#/c/503070" target="_blank">https://review.openstack.org/#<wbr>/c/503070</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Removing of_interface option and ovs-ofctl related code in Queens: <a href="https://review.openstack.org/#/c/503076" target="_blank">https://review.openstack.org/#<wbr>/c/503076</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Adoption of os-vif in Neutron (<a href="https://github.com/openstack/os-vif" target="_blank">https://github.com/openstack/<wbr>os-vif</a>)</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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 ( <a href="https://bugs.launchpad.net/neutron/+bug/1707156" target="_blank">https://bugs.launchpad.net/neu<wbr>tron/+bug/1707156</a>)</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Rodolfo Alonso is working on a PoC: <a href="https://review.openstack.org/#/q/status:open+branch:master+topic:osvif_migration" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+branch:master+t<wbr>opic:osvif_migration</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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 (<a href="https://github.com/openstack/neutron/blob/master/neutron/agent/linux/interface.py#L410" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/ag<wbr>ent/linux/interface.py#L410</a>)<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* David Shaughnessy is working on a PoC of a DVR OpenFlow implementation</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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.</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Kevin Benton will not have time to work on replacing l2_pop with information in the data model<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- We have a patch that never merged to setup arp_responder in the integration bridge: <a href="https://review.openstack.org/#/c/248177" target="_blank">https://review.openstack.org/#<wbr>/c/248177</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">-
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<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Kevin agreed to help review the code if we get someone to continue this work<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">* Linuxbridge<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- To fix the </span><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">Linuxbridge multinode job (<a href="https://bugs.launchpad.net/neutron/+bug/1683256" target="_blank">https://bugs.launchpad.net/ne<wbr>utron/+bug/1683256</a>),
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)<br></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Trunk scenario needs to be fixed to make the Linuxbridge scenario job stable<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">L3 flavors</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif">=======</span></p><span style="font-family:Arial,sans-serif">* The assignment of a service provider to a router is implemented as a callback subscribed to router create pre-commit event.<br></span><div style="margin-left:40px">- This mechanism can be racy.<br></div><div style="margin-left:40px">-
Isaku Yamahata and Manjeet Singh Bhatia have volunteered to work on
fixing the events systems, with Armando Migliaccio and Takashi Yamamoto
reviewing the code.</div>* Midonet supports IPv6 floating IPs but the reference implementation does not<br><div style="margin-left:40px">-
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</div><div style="margin-left:40px">- A decision was left pending on whether to support IPv6 floating IPs</div>* Currently we don't have a way to manage the compatibility or lack thereof between L3 flavors and ML2 drivers<br><div style="margin-left:40px">- Armando Migliaccio will propose an approach to handle this<br></div><div style="margin-left:40px"><span style="font-family:Arial,sans-serif"></span></div><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif"><br></font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">Floating IPs for routed networks</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">=======================</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">* A spec is up for review: <a href="https://review.openstack.org/#/c/486450/" target="_blank">https://review.openstack.org/#<wbr>/c/486450/</a>. It incorporates the feedback of one large operator (GoDaddy). Other operators are encouraged to review and provide feedback</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">*
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</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">* This is targeted for Queens</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif"><br></font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">Nova / Neutron integration</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">===================</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><font face="Arial, sans-serif">* Neutron port binding extension for live migration</font></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><font face="Arial, sans-serif">- This extension (spec:<a href="https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html" target="_blank">https://specs.openstack.<wbr>org/openstack/neutron-specs/sp<wbr>ecs/pike/portbinding_informati<wbr>on_for_nova.html</a></font><span style="font-family:Arial,sans-serif">) will provide an API to create bindings in multiple hosts for a port. Only one of those bindings can be active at a time</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif"><font color="rgb(17, 85, 204)">- When this extension is available, Nova </font>will use it to bind ports in the destination host during the </span><span style="font-family:Arial,sans-serif">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.</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif">- Previous work to wire L3 during the </span><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">pre_live_migration stage will be updated accordingly: <a href="https://review.openstack.org/#/c/275073/" target="_blank">https://review.openstack.org/#<wbr>/c/275073/</a>, <a href="https://review.openstack.org/#/c/275420/" target="_blank">https://review.openstack.org/#<wbr>/c/275420/</a>, <a href="https://review.openstack.org/#/c/260738/" target="_blank">https://review.openstack.org/#<wbr>/c/260738/</a><br></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">-
This work will proceed in parallel with the implementation of os-vif
object negotiation and could be merged at the end of the cycle</span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">- This work will also proceed in parallel with the move in Nova of the port orchestration to the conductor ( <a href="https://review.openstack.org/#/c/375580/" target="_blank">https://review.openstack.org/#<wbr>/c/375580/</a>)</span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">- Sean Mooney and Rodolfo Alonso will work on the Nova side. Miguel Lavalle will work on the Neutron side</span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">*
Using os-vif for port binding negotiation. Sean Mooney and Rodolfo
Alonso already have PoC code. They will continue the work during Queens</span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif">* Bandwidth-based scheduling<br></span></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">- Some work on the Neutron side has already started along the lines of the following spec: <a href="https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/strict-minimum-bandwidth-support.html" target="_blank">https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/ba<wbr>cklog/pike/strict-minimum-band<wbr>width-support.html</a>. Rodolfo Alonso, Slawek Kaplonski and Miguel Lavalle have committed to continue implementation in Queens<br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">-
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</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">Neutron to Neutron connectivity with BGPVPN</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">==============================<wbr>===</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">*
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.</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">-
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</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">- It was agreed that the next step will be to write a specification</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">Community related topics</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">==================</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">* The team brainstormed on steps to take to develop new core reviewers. The following actions were agreed upon:</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">-
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<br></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">- Establish deep dive sessions to train people on deep technical aspects of the different components of Neutron</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">- We are going to clean-up on-boarding documentation</p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px">- We are going to <span class="gmail-author-a-z122zgz86z0uyuz85z2uz84zlciyz85z">respin and maintain low-hanging-fruit list to address concerns over fruits being not very low hanging</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span class="gmail-author-a-z122zgz86z0uyuz85z2uz84zlciyz85z">-
We will identify areas where contributors are needed, using as a
starting point
<a href="https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#core-review-hierarchy">https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#core-review-hierarchy</a><br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span class="gmail-author-a-z122zgz86z0uyuz85z2uz84zlciyz85z">* Bug management issues. Over the past few months, we have had difficulty getting weekly volunteers to triage bugs</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span class="gmail-author-a-z122zgz86z0uyuz85z2uz84zlciyz85z">- We decided to define a fixed rotation among the team members. Miguel Lavalle will make a proposal</span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal;margin-left:40px"><span class="gmail-author-a-z122zgz86z0uyuz85z2uz84zlciyz85z">- We will follow up on implementing an IRC bot to notify in the Neutron channel the filing of new bugs<br></span></p><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:Arial,sans-serif"><span style="font-family:Arial,sans-serif"><br></span></span></p></div>