<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi All!<br><br></div>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.<br><br></div>You can find the etherpad we used during the PTG meetings here: <a href="https://etherpad.openstack.org/p/neutron-ptg-rocky" target="_blank">https://etherpad.openstack.org<wbr>/p/neutron-ptg-rocky</a><br><br><br></div>Retrospective<br>==========<br><br></div>* The team missed one community goal in the Pike cycle (<a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html" target="_blank">https://governance.openstack.<wbr>org/tc/goals/pike/deploy-api-i<wbr>n-wsgi.html</a>) and one in the Queens cycle (<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><br></div><div>   - Akihiro Motoki will work on <a href="https://governance.openstack.org/tc/goals/queens/policy-in-code.html" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/queens/policy-in-c<wbr>ode.html</a> during Rocky<br></div><div><br></div><div>  - We need volunteers to complete <a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html" target="_blank">https://governance.op<wbr>enstack.org/tc/goals/pike/depl<wbr>oy-api-in-wsgi.html</a>) and the two new goals for the Rocky cycle: <a href="https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/rocky/enable-mutab<wbr>le-configuration.html</a> and <a href="https://governance.openstack.org/tc/goals/rocky/mox_removal.html" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/rocky/mox_removal.<wbr>html</a>. Akihiro Motoki will lead the effort for mox removal<br></div><div><br>  - 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<br></div><div><br></div>* 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<br><br></div>* 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.<br><br></div>* 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:<br><br>   - Adopt oslo.versionedobjects for database interactions. This is a continuing effort. The contact is Ihar Hrachyshka  (<span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z78zz65zz82z592z66zh2dauz81zfz80zz68z"></span><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">ihrachys). Contributors are wanted. There is a weekly meeting led by Ihar where this topic is covered: <a href="http://eavesdrop.openstack.org/#Neutron_Upgrades_Meeting" target="_blank">http://eavesdrop.openstack.org<wbr>/#Neutron_Upgrades_Meeting</a><br><br>   - <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-">Enable adoption of an existing subnet into a subnetpool</span>. The final patch in the series to implement this feature is: <a href="https://review.openstack.org/#/c/348080" target="_blank">https://review.openstack.org/#<wbr>/c/348080</a>. Pawel Suder will drive this patch to completion<br><br>   - Neutron in-tree API reference (<a href="https://blueprints.launchpad.net/neutron/+spec/neutron-in-tree-api-ref" target="_blank">https://blueprints.launchpad.<wbr>net/neutron/+spec/neutron-in-t<wbr>ree-api-ref</a>). There are two remaining TODOs to complete this blueprint: <a href="https://bugs.launchpad.net/neutron/+bug/1752274" target="_blank">https://bugs.launchpad.net/neu<wbr>tron/+bug/1752274</a> and <a href="https://bugs.launchpad.net/neutron/+bug/1752275" target="_blank">https://bugs.launchpad.net/neu<wbr>tron/+bug/1752275</a>. We need volunteers for these two work items<br><br>   - Add TCP/UDP port forwarding extension to L3. The spec was merged recently: <a href="https://specs.openstack.org/openstack/neutron-specs/specs/queens/port-forwarding.html" target="_blank">https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/qu<wbr>eens/port-forwarding.html</a>. Implementation effort is in progress: <a href="https://review.openstack.org/#/c/533850/" target="_blank">https://review.openstack.org/#<wbr>/c/533850/</a> and  <a href="https://review.openstack.org/#/c/535647/" target="_blank">https://review.openstack.org/#<wbr>/c/535647/</a><br><br>   - Pure Python driven Linux network configuration (<a href="https://bugs.launchpad.net/neutron/+bug/1492714" target="_blank">https://bugs.launchpad.net/ne<wbr>utron/+bug/1492714</a>). This effort has been going on for several cycles gradually adopting pyroute2. Slawek Kaplonski is continuing it with <a href="https://review.openstack.org/#/c/545355" target="_blank">https://review.openstack.org/#<wbr>/c/545355</a> and <a href="https://review.openstack.org/#/c/548267" target="_blank">https://review.openstack.org/#<wbr>/c/548267</a><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><br>Port behind port API proposal<br>======================<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* 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: <a href="https://bugs.launchpad.net/bugs/1730845">https://bugs.launchpad.net/bugs/1730845</a><br><br>   - After discussing the proposed use cases, the agreement was to develop a specification making sure input is provided by the Kuryr and Octavia teams<br><br><br>ML2 and Mechanism drivers<br>=====================<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Hongbin Lu presented a proposal (<a href="https://bugs.launchpad.net/neutron/+bug/1722720" target="_blank">https://bugs.launchpad.net/ne<wbr>utron/+bug/1722720</a>) to add a new value "auto" to the port attribute admin_state_up. <br><br>   - 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<br>   - 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<br><br>* Zhang Yanxian presented a specification (<a href="https://review.openstack.org/506066" target="_blank">https://review.openstack.org/<wbr>506066</a>) 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. <br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   -  Nikolai de Figueiredo agreed to help to drive this effort forward, starting with the specification both in the Neutron and the Nova sides<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Sam Betts indicated this type of bond is also of interest for Ironic. He requested to be kept in the loop<br><br>* <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-">Ruijing Guo</span> proposed to support VLAN transparency in Neutron OVS agent.<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - There is a previous incomplete effort to provide this support: <a href="https://bugs.launchpad.net/neutron/+bug/1705719" target="_blank">https://bugs.launchpad.net/neu<wbr>tron/+bug/1705719</a>. Patches are here: <a href="https://review.openstack.org/#/q/project:openstack/neutron+topic:bug/1705719" target="_blank">https://review.openstack.org/#<wbr>/q/project:openstack/neutron+t<wbr>opic:bug/1705719</a><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Agreement was for Ruijing to look at the existing patches to re-start the effort. Thomas Morin may provide help for this<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - While on this topic, the conversation temporarily forked to the use of registers instead of <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-author-a-z75zz72zz86zz72zz65zz73zz67zz79zmo45d6um">ovsdb port tags</span> in L2 agent br-int and possibly remove br-tun. Thomas Morin committed to draft a RFE for this.<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Mike Kolesnik</span>, 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<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Currently each sub-project / SDN framework has its own solution for this problem. The group thinks that a common solution can be achieved<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was to create a specification where the common solution can be fleshed out<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The synchronization mechanism will exist in Neutron<br><br>* M<span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">ike Kolesnik</span></span> (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<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The conclusion was that there is no value in that practice for the sub-rpojects<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Sam Betts and Miguel Lavalle will explore moving unit tests utils to neutron-lib to enable subprojects to create their own base classes<br>   - <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">M<span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">ike Kolesnik</span></span></span> will document a guideline for sub-projects not to inherit unit tests from Neutron<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><br>API topics<br>========<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Isaku Yamahata presented a proposal of a new API for cloud admins to retrieve the physical networks configured in compute hosts<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - This information is currently stored in configuration files. In agent-less environments it is difficult to retrieve<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was to extend the agent API to expose the physnet as a standard attribute. This will be fed by a pseudo-agent<br><br>* <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Isaku Yamahata presented a proposal of a new API</span> to report mechanism drivers health<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Thomas Morin pointed out that this is relevant not only for ML2 mechanism drivers but also for all drivers of different services<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was to start with a specification where we scope the proposal into something manageable for implementation<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Yushiro Furukawa proposed to add support of 'snat' as a loggable resource type: <a href="https://bugs.launchpad.net/neutron/+bug/1752290" target="_blank">https://bugs.launchpad.net/neu<wbr>tron/+bug/1752290</a><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was to implement it in Rocky<br>   - Brian Haley agreed to be the approver<br><br>* Hongbin Lu indicated that If users provide different kinds of invalid query parameters, the behavior of the Neutron API looks unpredictable (<a href="https://bugs.launchpad.net/neutron/+bug/1749820" target="_blank">https://bugs.launchpad.net/ne<wbr>utron/+bug/1749820</a>)<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The proposal is to improve the predictability of the Neutron API by handling invalid query parameters consistently<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The proposal was accepted. It will need to provide API discoverability when behavior changes on filter parameter validation<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - It was also recommended to discuss this with the API SIG to get their guidance. The discussion already started in the mailing list: <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-March/128021.html">http://lists.openstack.org/pipermail/openstack-dev/2018-March/128021.html</a><br><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Openflow Manager and Common Classification Framework<br>==============================<wbr>============<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* The Openflow manager implementation needs reviews to continue making progress<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The approved spec is here: <a href="https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/l2-extension-ovs-flow-management.html" target="_blank">https://specs.openstack.org/op<wbr>enstack/neutron-specs/specs/ba<wbr>cklog/pike/l2-extension-ovs-fl<wbr>ow-management.html</a><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The code is here: <a href="https://review.openstack.org/323963" target="_blank">https://review.openstack.org/3<wbr>23963</a><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* The Common Classification Framework (<a href="https://specs.openstack.org/openstack/neutron-specs/specs/pike/common-classification-framework.html" target="_blank">https://specs.openstack.org/o<wbr>penstack/neutron-specs/specs/p<wbr>ike/common-classification-fram<wbr>ework.html</a>) needs to be adopted by its potential consumers: QoS, SFC, FWaaS<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">David Shaughnessy and Miguel Lavalle</span> met with Slawek Kaplonski over IRC the last day of the PTG  (<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2018-03-02.log.html#t2018-03-02T12:00:34" target="_blank">http://eavesdrop.openstack.or<wbr>g/irclogs/%23openstack-neutron<wbr>/%23openstack-neutron.2018-03-<wbr>02.log.html#t2018-03-02T12:00:<wbr>34</a>) 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<br><br>   - <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">David Shaughnessy</span></span> and <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Yushiro Furukawa</span> are going to meet to discuss adoption of the framework in FWaaS<br><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Neutron to Neutron interconnection<br>=========================<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Thomas Morin walked the team through an overview of his proposal (<a href="https://review.openstack.org/#/c/545826" target="_blank">https://review.openstack.org/<wbr>#/c/545826</a>) for Neutron to Neutron interconnection, whereby the following requirements are satisfied:<br><br>   - Interconnection is consumable on-demand, without admin intervention<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Have network isolation and allow the use of private IP addressing end to end<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Avoid the overhead of packet encryption<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Feedback was positive and the agreement is to continue developing and reviewing the specification<br><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">L3 and L3 flavors<br>============<br><br>* <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Isaku Yamahata </span>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<br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was an approach based on assigning a priority structure to callbacks in neutron-lib: <a href="https://review.openstack.org/#/c/541766" target="_blank">https://review.openstack.org/#<wbr>/c/541766</a><br><br>* <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Isaku Yamahata</span></span> shared with the team the progress made with the PoC for an Openflow based DVR: <a href="https://review.openstack.org/#/c/472289/" target="_blank">https://review.openstack.org/#<wbr>/c/472289/</a> and <a href="https://review.openstack.org/#/c/528336/" target="_blank">https://review.openstack.org/#<wbr>/c/528336/</a><br><br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br></span></div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - There was also an agreement for David Chou add Tempest testing for the scenario of mixed agents<br><br></span><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"><br>neutron-lib</span><br>========<br><br></div><div>* The team reviewed two neutron-lib specs, providing feedback through Gerrit:<br><br>   - A spec to rehome db api and utils into neutron-lib: <a href="https://review.openstack.org/#/c/473531" target="_blank">https://review.openstack.org/#<wbr>/c/473531</a>.<br>   - A spec to decouple neutron db models and ovo for neutron-lib: <a href="https://review.openstack.org/#/c/509564/" target="_blank">https://review.openstack.org/#<wbr>/c/509564/</a>. 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<br><br>* Manjeet Singh Bhatia proposed making payload consistent for all the callbacks so all the operations of an object get same type of payload. (<a href="https://bugs.launchpad.net/neutron/+bug/1747747" target="_blank">https://bugs.launchpad.net/ne<wbr>utron/+bug/1747747</a>)<br><br></div><div>   - The agreement was for Manjeet <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">to document all the instances in the code where this is happening so he and others can work on making the payloads consistent<br><br><br>Proposal to migrate neutronclient python bindings to OpenStack SDK<br>==============================<wbr>====================<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* 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 (<a href="http://lists.openstack.org/pipermail/openstack-dev/2018-February/127726.html" target="_blank">http://lists.openstack.org/pi<wbr>permail/openstack-dev/2018-Feb<wbr>ruary/127726.html</a>)<br><br>   - 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<br>   - New features should be supported in OpenStack SDK and OSC/neutronclient OSC plugin as the first priority<br>   - 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<br>   - 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<br>   - 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<br>   - 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<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Proposal was accepted<br><br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">Cross project planning with Nova<br>========================<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* 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:<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472"><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - Minimum bandwidth support guarantees a port minimum bandwidth. Strict minimum bandwidth support requires cooperation with the Nova scheduler, to avoid physical interfaces bandwidth overcommitment<br>   - 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<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br>   - Two new standard Resource Classes will be defined to represent the bandwidth in each direction, named as `NET_BANDWIDTH_INGRESS_BITS_SE<wbr>C` and `NET_BANDWIDTH_EGRESS_BITS_SEC<br>   - 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<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br>   - 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<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - For the first implementation, Neutron should reject a QoS minimum bandwidth policy rule created on a bound port<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - 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<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - For more detailed discussion, please go to the following specs: <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472"><a href="https://review.openstack.org/#/c/502306" target="_blank">https://review.openstack.org/#<wbr>/c/502306</a> and <a href="https://review.openstack.org/#/c/508149" target="_blank">https://review.openstack.org/#<wbr>/c/508149</a></span><br><br>* Provide Port Binding Information for Nova Live Migration (<a href="https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html" target="_blank">https://specs.openstack.org/<wbr>openstack/neutron-specs/specs/<wbr>backlog/pike/portbinding_<wbr>information_for_nova.html</a> and <a href="https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/neutron-new-port-binding-api.html" target="_blank">https://specs.openstack.org/<wbr>openstack/nova-specs/specs/<wbr>queens/approved/neutron-new-<wbr>port-binding-api.html</a>).<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - There was no discussion around this topic<br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - There was only an update to both teams about the solid progress that has been made on both sides: <span class="gmail-m_3767055240011633370gmail-author-a-z88z7jtz75zz85zqxxieyt472"></span><span class="gmail-m_3767055240011633370gmail-author-a-z88z7jtz75zz85zqxxieyt472 gmail-m_3767055240011633370gmail-url"><a href="https://review.openstack.org/#/c/414251/" target="_blank">https://review.openstack.org/#<wbr>/c/414251/</a></span> and <a href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/neutron-new-port-binding-api" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+project:<wbr>openstack/nova+branch:master+<wbr>topic:bp/neutron-new-port-<wbr>binding-api</a><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The plan is to finish this in Rocky<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* NUMA aware switches <span class="gmail-m_3767055240011633370gmail-author-a-4nxz83z0rz66zm7oz72zlsxuz71z"> </span><span class="gmail-m_3767055240011633370gmail-author-a-g7z122zz88zuvz74zz76zqgkz90zcz88ziz72z gmail-m_3767055240011633370gmail-url"><a href="https://review.openstack.org/#/c/541290/" target="_blank">https://review.openstack.org/#<wbr>/c/541290/</a></span><br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement on this topic was to do <span class="gmail-m_3767055240011633370gmail-author-a-g7z122zz88zuvz74zz76zqgkz90zcz88ziz72z">this during Rocky entirely in Nova using a config option which is a list of JSON blobs</span><br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Miguel Lavalle and Hongbin Lu proposed to <span class="gmail-m_3767055240011633370gmail-author-a-z88z7jtz75zz85zqxxieyt472">add device_id of the associated port to the floating IP resource</span><br><br>   - <span class="gmail-m_3767055240011633370gmail-author-a-z88z7jtz75zz85zqxxieyt472">The use case is to allow Nova to filter instances by floating IPs</span><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">   - The agreement was that <span class="gmail-m_3767055240011633370gmail-author-a-g7z122zz88zuvz74zz76zqgkz90zcz88ziz72z">this would be adding an entirely new contract to Nova with new query parameters. This will not be implemented in Nova, especially since </span><span class="gmail-m_3767055240011633370gmail-author-a-g7z122zz88zuvz74zz76zqgkz90zcz88ziz72z">the use case can already be fulfilled by making 3 API calls in a client: </span><span class="gmail-m_3767055240011633370gmail-author-a-4nxz83z0rz66zm7oz72zlsxuz71z">find floating IP via filter (Neutron), use that to filter port to get the device_id (Neutron), use that to get the server (Nova)</span><br><br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">Team photos<br>=========<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Thanks to Kendall Nelson, the official PTG team photos can be found here: <a href="https://www.dropbox.com/sh/dtei3ovfi7z74vo/AABT7UR5el6iXRx5WihkbOB3a/Neutron?dl=0" target="_blank">https://www.dropbox.com/sh/<wbr>dtei3ovfi7z74vo/<wbr>AABT7UR5el6iXRx5WihkbOB3a/<wbr>Neutron?dl=0</a><br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472">* Thanks to <span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472">Nikolai de Figueired</span>o for sharing with us pictures of our team dinner. Please find a couple of them attached to this message<br><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-author-a-z88z7jtz75zz85zqxxieyt472"><span class="gmail-m_3767055240011633370gmail-author-a-z88z7jtz75zz85zqxxieyt472"></span><br></span></div><div><span class="gmail-m_3767055240011633370gmail-m_-2346763831499589864gmail-m_-6038102572769408447gmail-m_6379454052003650046m_-4137210357060137659gmail-m_-2717938114555173189gmail-author-a-z88z7jtz75zz85zqxxieyt472"></span></div></div>