<div dir="ltr"><div><div>Kevin,<br><br></div>Thanks for putting this together. Regarding the point about DVR, "Allow DVR to perform floating IP translations at central node if<br>
compute node has no external network access", we already have a RFE, thanks to Swami: <a href="https://bugs.launchpad.net/neutron/+bug/1667877">https://bugs.launchpad.net/neutron/+bug/1667877</a><br><br></div>Cheers<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 4:47 AM, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
Following below is a high-level update of what was discussed during<br>
the PTG. If there is something I left out, I either forgot about it or<br>
didn't get a chance to sync up with the contributors and I don't have<br>
a summary so please reply to this email thread to add it. However, if<br>
you want to continue the discussion on any of these individual points,<br>
please start a new email thread so we don't have a ton of discussions<br>
going on attached to a single mega-thread.<br>
<br>
I apologize in advance because this is pretty long even though I tried<br>
to summarize as much as possible. :)<br>
<br>
Gate jobs/failures<br>
==============<br>
* Functional job: In order to bring the failure related to the OVSDB<br>
native interface timeouts we are going to try reducing the concurrency<br>
and then splitting out the OVSDB native interface tests into a<br>
separate non-voting job as a last resort.<br>
* Fullstack job: See if reducing concurrency brings down failure rate<br>
since each test is spawning multiple threads for agents/servers/etc.<br>
* Reducing job count: consolidate many existing jobs. For example,<br>
multi-node grenade only instead of single-node grenade jobs, no legacy<br>
routing jobs with OVS, etc.<br>
* Jobs for other projects (e.g. dragonflow, tripleo, ironic). We need<br>
to consider having post-merge triggers for these since they are just<br>
meant to be a way to trace when Neutron introduces a failure into<br>
their project and regular Neutron contributors won't pay attention to<br>
their check queue status.<br>
* OVS compilation from source: stop doing this for as many jobs as<br>
possible so we test what is shipped with the distro.<br>
* Bug Triage: current bug deputy system working well<br>
* Gate failures: encourage use of elastic recheck and Ihar enabled the<br>
IRC bot to message the channel for elastic recheck failures.<br>
<br>
Review Backlog<br>
============<br>
* Making frequent use of the auto-abandon script so we don't go quite<br>
so long when contributors don't reply to negative feedback.<br>
* Un-assign the bug assignee when patches are auto-abandoned.<br>
* Generate email of abandoned patches to bring to wider attention.<br>
* Look into IRC notifications for patches that require core reviewer<br>
feedback that have been sitting for weeks.<br>
<br>
Neutron-lib<br>
=========<br>
* Releases: switch to more frequent release cycle so consumers get<br>
changes faster. Release after weekly meeting if someone requests it.<br>
* Review velocity: solicit more reviews from Neutron and stadium<br>
project cores since they have +2 power. Then drivers can more easily<br>
scan for patches ready to merge for final +W.<br>
<br>
OpenStack goals<br>
=============<br>
* mod_wsgi support: Add dedicated RPC server, create entry script for<br>
mod_wsgi, switch to pecan.<br>
* python3 support: switch some tempest jobs to python3 and leave some<br>
in python2 to avoid explosion of job types while maintaining decent<br>
coverage.<br>
* Storyboard: we can't really adopt this until the other core projects<br>
do since we have a lot of cross-project bugs.<br>
<br>
Stadium Changes<br>
==============<br>
* Tap as a service intends to be included in Pike<br>
* Stadium requirements will now include python3 support since it's a<br>
community-wide goal. Projects should run tempest tests for both<br>
python2 and python3 since python2 support won't be dropped.<br>
* For Pike we will try to synchronize releases.<br>
<br>
Tempest tests<br>
===========<br>
* Use tempest stable API for our tests (tempest-lib)<br>
* Split out our tempest tests into a separate branchless repo<br>
<br>
Documentation<br>
============<br>
* DocImpact tag. Always include a one-sentence summary of what docs<br>
need to be added/changed.<br>
* Consider requiring at least some initial documentation from the<br>
feature developer as a WIP patch to docs before allowing feature<br>
merges.<br>
<br>
No downtime upgrades<br>
==================<br>
* Need online-db-migration option to neutron-db-manage like other projects have<br>
* Need mechanism to disable new features in new servers until all old<br>
servers are taken offline.<br>
* Finish adoption of OVO across the code-base by reviewing outstanding patches.<br>
* Consider moving some OVO base classes into neutron-lib so other<br>
neutron projects can start adopting OVO for their custom objects.<br>
* Figure out how to handle case where a different DB table provides an<br>
API field depending on the loaded core plugin (e.g. port bindings).<br>
<br>
New Network Types<br>
===============<br>
* Explore how a new "network-type" field might be implemented that can<br>
be used to get non-L2 networks where the IP addressing and segment<br>
semantics currently offered by ML2 don't fit well. RFE:<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1664466" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>neutron/+bug/1664466</a><br>
* We could consider making use of the flavor framework for dispatching<br>
calls to different plugins, but this will require some significant<br>
refactoring and considerations for things like different extensions<br>
supported by different plugins.<br>
<br>
EngineFacade Switch<br>
=================<br>
* Outstanding reviews:<br>
<a href="https://review.openstack.org/#/q/topic:bp/enginefacade-switch+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/enginefacade-<wbr>switch+status:open</a><br>
* Figuring out a strategy to load relationships on newly created<br>
sqlalchemy objects to ensure we don't emit queries after the<br>
transaction is closed: <a href="https://review.openstack.org/#/c/434454/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/434454/</a><br>
<br>
Push Notifications<br>
==============<br>
* Needs some reviews for the L2 code:<br>
<a href="https://review.openstack.org/#/q/topic:bp/push-notifications+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/push-<wbr>notifications+status:open</a><br>
* Once L2 code has landed, we can re-use much of the same logic for<br>
the L3 agent and DHCP agent.<br>
<br>
Extensions (not)Supported by Loaded ML2 Drivers<br>
==============================<wbr>=========<br>
* Generic mechanism being developed by ML2 contributors to ensure that<br>
the necessary drivers in a given port binding are actually enforcing<br>
the extensions requested by the port model (e.g. security groups, QoS,<br>
etc).<br>
* Will reconcile with QoS-specific approach to validation here:<br>
<a href="https://review.openstack.org/#/c/426946/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/426946/</a><br>
<br>
Neutronclient -> OSC Transition<br>
=========================<br>
* Continue migration of commands. Status here:<br>
<a href="https://docs.google.com/spreadsheets/d/18ZtWC75BNCwFqLfFpCGGJ9uPVBvUXX0xuXP1yYG0NDA/" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>spreadsheets/d/<wbr>18ZtWC75BNCwFqLfFpCGGJ9uPVBvUX<wbr>X0xuXP1yYG0NDA/</a><br>
* Only high/critical priority bug fixes to neutronclient at this<br>
point. No new features.<br>
<br>
Nova/Neutron Integration<br>
===================<br>
* Add a new API for nova to retrieve all things related to a port in<br>
one call (e.g. networks, subnets, floating IPs, subports, etc).<br>
<a href="https://review.openstack.org/#/c/390513/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/390513/</a><br>
* Negotiate and return os-vif objects from Neutron to Nova on port<br>
binding. <a href="https://review.openstack.org/#/c/390512/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/390512/</a><br>
* Continue multiple port bindings work for live migration case.<br>
<a href="https://review.openstack.org/#/c/414251/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/414251/</a><br>
* Avoid making any of these dependent on each other since we need to<br>
ensure os-vif has parity with all of the existing plugging Nova can do<br>
before strictly returning os-vif objects.<br>
<br>
Ironic/Neutron Integration<br>
===================<br>
* Ironic support for routed networks:<br>
<a href="https://docs.google.com/document/d/1hekOPBPCuehD9KCI0vJcW0zDaih8BCDeHqL461kw5dA/" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>1hekOPBPCuehD9KCI0vJcW0zDaih8B<wbr>CDeHqL461kw5dA/</a><br>
* vlan-aware-vms support addressed by <a href="https://review.openstack.org/#/c/436756/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/436756/</a><br>
<br>
DVR<br>
====<br>
* Allow DVR to work with unbound ports by scheduling to central node.<br>
Pending RFE.<br>
* Allow DVR to perform floating IP translations at central node if<br>
compute node has no external network access. Pending RFE.<br>
* Allow DVR to burn more external IPs and do SNAT at the compute node.<br>
Pending RFE.<br>
* Examine offloading east-west routing to openflow.<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1509184" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>neutron/+bug/1509184</a><br>
<br>
L3HA<br>
====<br>
* This spreadsheet was put together to examine failure cases of<br>
current solutions: <a href="https://ethercalc.openstack.org/Pike-Neutron-L3-HA" rel="noreferrer" target="_blank">https://ethercalc.openstack.<wbr>org/Pike-Neutron-L3-HA</a><br>
* There does not appear to be enough interest upstream to develop an<br>
alternative approach using something other than keepalived in-tree. So<br>
an alternative will need to be developed out of tree first and then be<br>
considered for inclusion after it's shown to work well.<br>
* We should examine downgrading VRRP priority on track script failure<br>
and allow preemption to avoid a full outage if upstream gateway stops<br>
responding to ping.<br>
<br>
OVS native interfaces<br>
=================<br>
* OVSDB: split out into a separate repo since we have several projects<br>
consuming it. <a href="https://review.openstack.org/#/c/438086/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/438086/</a><br>
* OVSFW: switch the devstack default to the OVS native firewall and<br>
implement logic to cleanup iptables rules on hybrid bridges so we have<br>
a minimal migration path. Rolling migration will work to eliminate<br>
hybrid bridge once multiple port bindings is implemented in Nova.<br>
<br>
Common Classification Framework<br>
===========================<br>
* Spec is here with notes from PTG discussions:<br>
<a href="https://review.openstack.org/#/c/333993/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/333993/</a><br>
<br>
Security Groups Logging<br>
===================<br>
* Target OVS native firewall for logging actions since that will<br>
become the devstack default.<br>
* Spec: <a href="https://review.openstack.org/#/c/203509/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/203509/</a><br>
<br>
SR-IOV<br>
======<br>
* Development of new ML2 type drivers to allow some NFV and tripleO<br>
use cases: QinQ with VM setting inner tag, VLAN filters for<br>
VLAN-transparent networks, QinQ double tag applied to untagged traffic<br>
from VM. All pending RFEs.<br>
<br>
FWaaS<br>
======<br>
* Target OVS native firewall for compute-node filtering since that<br>
will become the devstack default<br>
* FWaaS internal development etherpad:<br>
<a href="https://etherpad.openstack.org/p/fwaas-pike" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/fwaas-pike</a><br>
<br>
LBaaS<br>
=====<br>
* Switch is in progress. We need the shim layer in Neutron to not<br>
break old clients. <a href="https://review.openstack.org/#/c/418530/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/418530/</a><br>
<br>
VPNaaS<br>
=======<br>
* We have several contributors interested in keeping it maintained and<br>
alive. We just need to get the testing/documentation/etc fixed up to<br>
bring it back into the stadium.<br>
<br>
<br>
Cheers,<br>
Kevin Benton<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>