[openstack-dev] [Neutron][Nova] Neutron mid-cycle summary report
armamig at gmail.com
Sat Aug 27 00:13:34 UTC 2016
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.
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.
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!!
Feel free to reach out/add if something is unclear, incorrect or incomplete.
We touched on these topics (as initially proposed on
- Keystone v3 and project-id adoption:
- dasm and amotoki have been working to making the Neutron server
process project-id correctly . Looking at the spec , we
are half way
through having completed the DB migration, being Keystone v3
having updated the client bindings .
-  https://review.openstack.org/#/c/357977/
-  https://review.openstack.org/#/c/257362/
-  https://review.openstack.org/#/q/topic:bp/keystone-v3
- HenryG, dougwig and kevinbenton worked out a plan to get the
into neutron-lib. Because of the risk of regression, this is
until Ocata opens up. However, simpler changes like the he model_base
move to lib was agreed on and merged.
- 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
- rtheis and armax worked on having networking-ovn test periodically
against neutron-lib [1,2,3].
-  https://review.openstack.org/#/c/357086/
-  https://review.openstack.org/#/c/359143/
-  https://review.openstack.org/#/c/357079/
- A tool (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.
- Right now neutron-lib 0.4.0 is released and available in
- Objects and hitless upgrades:
- Ihar gave the team an overview and status update 
- There was a fruitful discussion that hopefully set the way forward
for Ocata. The discussed plan was to start Ocata with the
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.
- 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
-  http://lists.openstack.org/pipermail/openstack-dev/
- OSC transition:
- 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.
- 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.
- 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.
- Several pending contributions into osc-lib.
- An update is available on [1,2]
-  https://review.openstack.org/#/c/357844/
-  https://etherpad.openstack.org/p/osc-neutron-support
- Stability squash:
- armax was bug deputy for the week of the mid-cycle; nothing
critical showed up in the gate, however pluggable ipam  switch merged,
which might have some unexpected repercussions down the road.
- A number of bugs older than a year were made expirable .
- kevinbenton and armax devised a strategy and started working on 
to ensure DB retriable errors are no longer handled at the API layer.
- The gate witnessed phantom resets that turned out to be related to
- 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
- jlibosva should follow up with patches to make fullstack/functional
job "bullet proof";
- armax to make a case for check queue only voting status for
-  https://review.openstack.org/#/c/181023/
-  https://bugs.launchpad.net/neutron/+expirable-bugs
-  https://review.openstack.org/#/c/356530/
-  https://bugs.launchpad.net/devstack/+bug/1616282
- Stadium wide efforts:
- 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 , which he is using to break ground.
- API reference clean up sprint has been announced and started.
on the API reference was prepared . Some lead-by-example patches have
been posted and merged .
-  https://review.openstack.org/#/c/353131/
-  https://etherpad.openstack.org/p/neutron-api-ref-sprint
-  https://review.openstack.org/#/c/350857/
- Nova/Neutron integration
- 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
- 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
- armax, johnthetubaguy, ihrachys talked about next steps in order to
allow os-vif to access a versioned object of vif details as stored by
- carl_baldwin was able to make some progress on  to abort build
if Nova tries to schedule a vm to a segment where the IP is not usable.
-  https://review.openstack.org/#/c/309416/
-  https://review.openstack.org/#/c/353982/
-  https://review.openstack.org/#/c/346278/
- Newton blueprints (in no particular order):
- 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.
- service subnets:
- Spent some time tying up some final loose ends on the service
subnets capability. Patch  was the final one of the
effort. Need to get
the release note written and merged it.
-  https://review.openstack.org/#/c/350613
- routed networks:
- mlavalle implemented a Generic Resource Pools client 
leveraged in .
- 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.
was able to provide an example and we're working to wrap that
up now .
- carl_baldwin discussed the patch  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
would be of great help.
-  https://github.com/miguellavalle/python-
-  https://review.openstack.org/#/c/358658/
-  https://review.openstack.org/#/c/293305
-  https://review.openstack.org/#/c/317358
- jlibosva and armax talked about how to deal with failures during
OVS trunk setup. That resulted in jlibosva working on on
manager to handle nested transaction.
- armax and tidwellr are working on completing the trunk state
- kevinbenton is rebasing/working on the linuxbridge driver
- OVN driver coming along as well.
- Resource status:
- Many Neutron resources have status/admin_state_up attributes,
however their meaning is not consistent across. This makes difficult to
address use cases like . 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  more informed.
-  https://review.openstack.org/#/c/351675/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev