Network/Meetings
The OpenStack Networking Team (Neutron) holds public meetings as advertised on OpenStack IRC Meetings Calendar. If you are unable to attend, please check the most recent logs.
Contents
Announcements / Reminders
- Next milestone, Rocky-1, April 16 - 20
- Rocky release schedule: https://releases.openstack.org/rocky/schedule.html
- Rocky PTG summary: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128183.html
Blueprints
Rocky-1 blueprints: https://launchpad.net/neutron/+milestone/rocky-1
OVO/no API downtime
List here patches/topics that need core reviewer attention.
- add your patch here
Community Goals
This slot is to used to track the progress of the community goals. https://governance.openstack.org/tc/goals/index.html#release-cycles
- policy-in-code (Queens) -- amotoki
- wsgi support (Pike) -- annp
- Enable mutable configuration (Rocky) https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html -- slaweq
- mox3 removal (Rocky) https://bugs.launchpad.net/python-neutronclient/+bug/1753504 -- hongbin (neutronclient), amotoki (fwaas/vpnaas-dashboard), (perhaps) yamamoto (networking-midonet)
- python3.5 fully support https://etherpad.openstack.org/p/py3-neutron-pike
Starter Approved RFEs
This section is for advertising approved RFEs that the Neutron Drivers team have deemed suitable for new contributors:
- Network router:external field not exported: https://bugs.launchpad.net/neutron/+bug/1653932
Bugs and Gate issues
Bug deputy report for week of March 12th: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128493.html
A full hour is dedicated to this topic, and more during the following meeting:
- https://wiki.openstack.org/wiki/Meetings/NeutronCI
- Confirmed gate failures
- Bugs that need attention
- All bug reports associated to deprecation issues
- Bugs Sheet
- Grafana dashboards
Bug deputy
You can find more information about what the role is here: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neutron-bug-deputy
During the Denver PTG we made the decision to institute a fixed rotation for the the bugs deputy role. The current scheduled rotation is the following:
Date | who |
---|---|
January-8-2018 | Hirofumi Ichihara (hichihara) |
January-15-2018 | Gary Kotton (garyk) |
January-22-2018 | Akihiro Motoki (amotoki) |
January-29-2018 | Jakub Libosvar (jlibosva) |
February-5-2018 | Boden Russel (boden) |
February-12-2018 | James Anziano (janzian) |
February-19-2018 | Ihar Hrachyshka (ihrachys) |
February-26-2018 | Slawek Kaplonski (slaweq) |
March-5-2018 | Brian Haley (haleyb) |
March-12-2018 | Zhao Bo(bzhao) |
March-19-2018 | Armando Migliaccio (armax) |
March-26-2018 | Swaminathan Vasudevan (Swami) |
April-2-2018 | Lujin Luo(lujinluo) |
April-9-2018 | YAMAMOTO Takashi (yamamoto) |
April-16-2018 | Miguel Lavalle (mlavalle) |
April-23-2018 | Pawel Suder (pasuder) |
April-30-2018 | Hongbin Lu (hongbin) |
In preparation for their duty week, deputies are encouraged to review the Neutron bugs policy: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html
Docs
- The future of OpenStack documentation - http://lists.openstack.org/pipermail/openstack-dev/2016-July/099012.html
- Documentation bugs - https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
CLI/SDK
SDK migration of neutronclient python bindings https://etherpad.openstack.org/p/neutron-openstacksdk-migration
Status of changes to deliver OSC (this needs to be revisit)
- https://etherpad.openstack.org/p/osc-transition-priorities
- http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html
Neutron-lib, planned refactoring and other impacts
List here any planned potential disruption that may be caused by a new neutron-lib release and adoption of its latest features.
DO NOT TOP POST - ADD PATCHES TO THE BOTTOM OF THE LIST
- Open issues: https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
- In most cases all consumers using neutron/neutron-lib stable branches are updated as part of consumption. For those who "pin" neutron/neutron-lib, they will have to address the consumption as they move their "pin" up.
- To see all consumption patches for a lib impact change, view the topic branch of the corresponding lib impact change (or search using the same subject).
- Patches that need high-level input from neutron cores: https://review.openstack.org/#/q/message:%22NeutronCoreInputNeeded%22
- Past issues: https://review.openstack.org/#/q/status:merged+message:%22NeutronLibImpact%22
- UpgradeImpact changes: https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron
- Periodic neutron-lib check: http://grafana.openstack.org/dashboard/db/neutron-lib-failure-rate?panelId=4&fullscreen
- <Highlight patch(es) here for discussion>
On Demand Agenda
We can only pick one or two topics we can talk in the time left of the meeting. People should add ideas to the topics section. We will select one or two topics we can chew during the next meeting. Please follow the template below:
- Topic for the meeting (keep this template, please):
- (your nickname): brief description.
- More details
- (your nickname): brief description.
- Typo fixing patches
- (jlibosva, slaweq) There has been some patches coming from a certain group of people that just fix one typo in either a comment in code or documentation. e.g. https://review.openstack.org/#/c/540225/ . There has been already a ML thread started about this behavior in our community: http://lists.openstack.org/pipermail/openstack-dev/2017-September/122472.html Although typo fixes bring some value, they bring a very tiny value being sent one by one as that triggers CI systems and require two cores to approve such patch. This topic is to kick off the discussion about what approach should Neutron cores take.
- Use of existing tools to aid backporting bugfixes etc. to stable branches
- (aspiers) I have written a Python module git-deps which can predict the complexity of porting tasks
- This could be wrapped in a non-voting check pipeline job to warn when complexity is above a certain threshold, and recommend that the backport be done now while the fix is fresh in the developer's head (or that the fix could be reworked to avoid potential conflicts during backport). Mentioned to mlavalle who suggested raising here. Worth discussing in Neutron CI meeting as well / instead?
- (aspiers) I have written another (as yet unpublished) tool git-explode which wraps git-deps and allows decomposition of logically related changes into separate git branches; this could potentially be used to accelerate backporting.
- (aspiers) Unfinished / unused tools from a long time ago to aid with more complex backporting - worth resurrecting?
- (ndefigueiredo) Stateless security groups - Email sent out addressing this.
- (aspiers) I have written a Python module git-deps which can predict the complexity of porting tasks
Previous meeting logs
- Previous meetings, with their notes and logs, can be found here.