<html><body><p>Not a bother. Great to have the Neutrinos in Cork ! :-)<br><br><br><img width="16" height="16" src="cid:1__=0FBB0A8DDFCAE95A8f9e8a93df938690918c0FB@" border="0" alt="Inactive hide details for "Armando M." ---27/08/2016 01:14:24---Hi Neutrinos, For those of you who couldn't join in person, ple"><font color="#424282">"Armando M." ---27/08/2016 01:14:24---Hi Neutrinos, For those of you who couldn't join in person, please find a few notes below</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">"Armando M." <armamig@gmail.com></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">Martin Hickey/Ireland/IBM@IBMIE</font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">27/08/2016 01:14</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[Neutron][Nova] Neutron mid-cycle summary report</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Hi Neutrinos,<br><br>For those of you who couldn't join in person, please find a few notes below to capture some of the highlights of the event.<br><br>I would like to thank everyone one who helped me put this report together, and everyone who helped make this mid-cycle a fruitful one.<br><br>I would also like to thank IBM, and the individual organizers who made everything go smoothly. In particular Martin, who put up with our moody requests: thanks Martin!!<br><br>Feel free to reach out/add if something is unclear, incorrect or incomplete.<br><br>Cheers,<br>Armando<br><br>~~~~~~~<br><br><font face="Arial">We touched on these topics (as initially proposed on </font><a href="https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems" target="_blank"><u><font color="#0000FF" face="Arial">https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems</font></u></a><font face="Arial">)</font><br>

<ul><ul type="disc"><li><font size="4">Keystone v3 and project-id adoption:<ul><ul type="disc"><li>dasm and amotoki have been working to making the Neutron server process project-id correctly [1]. Looking at the spec [2], we are half way through having completed the DB migration, being Keystone v3 complaint, and having updated the client bindings [3].

<ul><ul type="disc"><li>[1] <a href="https://review.openstack.org/#/c/357977/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/357977/</font></u></a><li>[2] <a href="https://review.openstack.org/#/c/257362/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/257362/</font></u></a><li>[3] <a href="https://review.openstack.org/#/q/topic:bp/keystone-v3" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/q/topic:bp/keystone-v3</font></u></a></ul></ul></ul></ul>

<li><font size="4">Neutron-lib:<ul><ul type="disc"><li><font size="4">HenryG, dougwig and kevinbenton worked out a plan to get the common_db_mixin into neutron-lib. Because of the risk of regression, this is being deferred until Ocata opens up. However, simpler changes like the he model_base move to lib was agreed on and merged.

<li>A plan to provide test support was discussed. The current strategy involves providing test base classes in lib (this reverses the stance conveyed in Austin). The usual steps involved require to making public the currently private classes, ensure the lib's copies are up-to-date with core neutron, and deprecate the ones located in Neutron.

<li>rtheis and armax worked on having networking-ovn test periodically against neutron-lib [1,2,3].

<ul><ul type="disc"><li>[1] <a href="https://review.openstack.org/#/c/357086/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/357086/</font></u></a><li>[2] <a href="https://review.openstack.org/#/c/359143/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/359143/</font></u></a><li>[3] <a href="https://review.openstack.org/#/c/357079/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/357079/</font></u></a></ul></ul>

<li>A tool (<font size="4">tools/migration_report.sh) helps project team determine the level of dependency they have with Neutron. It should be improved to report the exact offending imports.</font><li>Right now neutron-lib 0.4.0 is released and available in global-requirements/upper-constraints.</ul></ul>

<li><font size="4">Objects and hitless upgrades:<ul><ul type="disc"><li><font size="4">Ihar gave the team an overview and status update [1]<li>There was a fruitful discussion that hopefully set the way forward for Ocata. The discussed plan was to start Ocata with the expectation that no new contract scripts are landing in Ocata, and to revisit the requirement later if for some reason we see any issue with applying the requirement in practice.

<li>Some work was done to deliver necessary objects for push-notifications. Patches up for review. Some review cycles were spent to work on landing patches moving model definitions under neutron/db/models

<ul><ul type="disc"><li><font size="4">[1] </font><a href="http://lists.openstack.org/pipermail/openstack-dev/2016-August/101838.html" target="_blank"><u><font size="4" color="#0000FF">http://lists.openstack.org/pipermail/openstack-dev/2016-August/101838.html</font></u></a></ul></ul></ul></ul>

<li><font size="4">OSC transition:</font><ul><ul type="disc"><li><font size="4">rtheis gave an update to the team on the state of the transition. Core resources commands are all available through OSC; QoS, Metering and *-aaS are still not converted.</font><li><font size="4">There is some confusion on how to tackle openstacksdk support. We discussed the future goal of python binding of Networking API. OSC uses OpenStack SDK for network commands and Neutron OSC plugin uses python bindings from python-neutronclient. A question is to which project developers who add new features implement, both, openstack SDK or python-neutronclient? There was no conclusion at the mid-cycle. It is not specific to neutron. Similar situation can happen for nova, cinder and other projects and we need to raise it to the community.</font><li><font size="4">Ocata is going to be the first release where the neutronclient CLI is officially deprecated. It may take us more than the usual two cycles to remove it altogether, but that's a signal to developer and users to seriously develop against OSC, and report bugs against OSC.</font><li><font size="4">Several pending contributions into osc-lib.</font><li><font size="4">An update is available on [1,2]</font><ul><ul type="disc"><li><font size="4">[1] </font><a href="https://review.openstack.org/#/c/357844/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/357844/</font></u></a><li><font size="4">[2] </font><a href="https://etherpad.openstack.org/p/osc-neutron-support" target="_blank"><u><font size="4" color="#0000FF">https://etherpad.openstack.org/p/osc-neutron-support</font></u></a></ul></ul></ul></ul>

<li><font size="4">Stability squash:</font><ul><ul type="disc"><li><font size="4">armax was bug deputy for the week of the mid-cycle; nothing critical showed up in the gate, however pluggable ipam [1] switch merged, which might have some unexpected repercussions down the road.</font><li><font size="4">A number of bugs older than a year were made expirable [2].</font><li><font size="4">kevinbenton and armax devised a strategy and started working on [3] to ensure DB retriable errors are no longer handled at the API layer.</font><li><font size="4">The gate witnessed phantom resets that turned out to be related to [4].</font><li><font size="4">kevinbenton, jlibosva, armax, jschwarz talked about the Neutron job queue configuration; it would be desirable to start gating on rally, and fullstack jobs but this can be done once Ocata opens up. Testing L3 HA in the multinode configuration is something that needs tackling too. Ideally we'd move away from testing legacy routing in the gate to give resources to other priorities.  </font><li>jlibosva should follow up with patches to make fullstack/functional job "bullet proof";

<li>armax to make a case for check queue only voting status for functional/rally/fullstack jobs.

<ul><ul type="disc"><li><font size="4">[1] </font><a href="https://review.openstack.org/#/c/181023/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/181023/</font></u></a><li><font size="4">[2] </font><a href="https://bugs.launchpad.net/neutron/+expirable-bugs" target="_blank"><u><font size="4" color="#0000FF">https://bugs.launchpad.net/neutron/+expirable-bugs</font></u></a><li><font size="4">[3] </font><a href="https://review.openstack.org/#/c/356530/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/356530/</font></u></a><li><font size="4">[4] </font><a href="https://bugs.launchpad.net/devstack/+bug/1616282" target="_blank"><u><font size="4" color="#0000FF">https://bugs.launchpad.net/devstack/+bug/1616282</font></u></a></ul></ul></ul></ul>

<li><font size="4">Stadium wide efforts:<ul><ul type="disc"><li>There was a discussion around what our API definition is. Specifically, whether we consider supported queries part of it, and if so, if we plan to enforce this aspect in the future. Code inspection showed that it’s hard to determine query parameters supported by plugins right now. We will look into non-invasive ways to collect this data in Ocata. Armax to follow up on [1], which he is using to break ground.

<li>API reference clean up sprint has been announced and started. The guideline on the API reference was prepared [2]. Some lead-by-example patches have been posted and merged [3].

<ul><ul type="disc"><li><font size="4">[1] </font><a href="https://review.openstack.org/#/c/353131/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/353131/</font></u></a><li>[2] <a href="https://etherpad.openstack.org/p/neutron-api-ref-sprint" target="_blank"><u><font color="#0000FF">https://etherpad.openstack.org/p/neutron-api-ref-sprint</font></u></a><li>[3] <a href="https://review.openstack.org/#/c/350857/" target="_blank"><u><font color="#0000FF">https://review.openstack.org/#/c/350857/</font></u></a></ul></ul></ul></ul>

<li><font size="4">Nova/Neutron integration<ul><ul type="disc"><li>armax, johnthetubaguy and carl_baldin participated in a couple of discussions about live migration and multiple port binding. There is a common understanding of the problem and how to improve the resiliency of the boot/live migration operation. Some thoughts are being captured on [1,2]. The plan is to ensure all the legwork is complete ahead of the summit so that the team can switch into execution mode during the Ocata timeframe.

<li>There are areas where Nova talks to Neutron that can be improved and the team identified/discussed a few, the periodic polls being an example. Providing the ability to aggregate more data in a single API was also contemplated.

<li>armax, johnthetubaguy, <font size="4">ihrachys talked about next steps in order to allow os-vif to access a versioned object of vif details as stored by Neutron.

<li>carl_baldwin was able to make some progress on [3] to abort build if Nova tries to schedule a vm to a segment where the IP is not usable.

<ul><ul type="disc"><li>[1] <a href="https://review.openstack.org/#/c/309416/"><u><font color="#0000FF">https://review.openstack.org/#/c/309416/</font></u></a><li>[2] <a href="https://review.openstack.org/#/c/353982/"><u><font color="#0000FF">https://review.openstack.org/#/c/353982/</font></u></a><li>[3] <a href="https://review.openstack.org/#/c/346278/"><u><font color="#0000FF">https://review.openstack.org/#/c/346278/</font></u></a></ul></ul></ul></ul>

<li><font size="4">Newton blueprints (in no particular order):</font><ul><ul type="disc"><li><font size="4">push notifications: discussed future steps on how to implement compare and swap updates to reduce some of the races experienced when dealing with the Neutron API.</font><li>service subnets:

<ul><ul type="disc"><li>Spent some time tying up some final loose ends on the service subnets capability. Patch [1] was the final one of the effort. Need to get the release note written and merged it.

<ul><ul type="disc"><li>[1] <a href="https://review.openstack.org/#/c/350613"><u><font color="#0000FF">https://review.openstack.org/#/c/350613</font></u></a></ul></ul></ul></ul>

<li><font size="4">routed networks:<ul><ul type="disc"><li><font size="4">mlavalle implemented a Generic Resource Pools client [1] leveraged in [2].<li><font size="4">carl_baldwin and kevinbenton had a very productive discussion about how to add standard attributes to the networksegments table to complete its transition to being a first class API resource. kevinbenton was able to provide an example and we're working to wrap that up now [3].

<li>carl_baldwin discussed the patch [4] to enable creating and deleting segments with the ML2 plugin with kevinbenton. This may be the last hurdle for routed networks. Wrapping this up before feature freeze would be of great help. 

<ul><ul type="disc"><li><font size="4">[1] </font><a href="https://github.com/"><u><font size="4" color="#0000FF">https://github.com/</font></u></a><font size="4">miguellavalle/python-placementclient/tree/adding-grp-support</font><li><font size="4">[2] </font><a href="https://review.openstack/"><u><font size="4" color="#0000FF">https://review.openstack</font></u></a><font size="4">.org/#/c/358658/</font><li><font size="4">[3] </font><a href="https://review.openstack/"><u><font size="4" color="#0000FF">https://review.openstack</font></u></a><font size="4">.org/#/c/293305</font><li><font size="4">[4] </font><a href="https://review.openstack/"><u><font size="4" color="#0000FF">https://review.openstack</font></u></a><font size="4">.org/#/c/317358</font></ul></ul></ul></ul>

<li><font size="4">vlan-aware-vms:</font><ul><ul type="disc"><li><font size="4">jlibosva and armax talked about how to deal with failures during OVS trunk setup. That resulted in jlibosva working on on OVSDB transaction manager to handle nested transaction. </font><li><font size="4">armax and tidwellr are working on completing the trunk state machine,</font><li><font size="4">kevinbenton is rebasing/working on the linuxbridge driver</font><li><font size="4">OVN driver coming along as well.</font><li><a href="https://review.openstack.org/#/q/status:open+topic:bp/vlan-aware-vms" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/q/status:open+topic:bp/vlan-aware-vms</font></u></a></ul></ul></ul></ul>

<li><font size="4">Resource status:</font><ul><ul type="disc"><li><font size="4">Many Neutron resources have status/admin_state_up attributes, however their meaning is not consistent across. This makes difficult to address use cases like [1]. We should start painting a picture of what exactly each attribute mean for each resource in order to make sure we can approach to cases like [1] more informed.</font><ul><ul type="disc"><li><font size="4">[1] </font><a href="https://review.openstack.org/#/c/351675/"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/351675/</font></u></a><font size="4"> </font><br>

<p></ul></ul></ul></ul></ul></ul><BR>

</body></html>