[openstack-dev] [neutron] Bug deputy report, week August 5th - August 12th
I was the bug deputy for the August 6th - August 12th week (6th exclusive, it was handled by Miguel, thanks to him). A mostly quiet week, most issues came with related fix (and some already merged). Interesting topics: API performance improvement (1786226), a few fixes for metering agent, a DVR bug/discussion (1786169), API performance improvement (1786226), some test fixes High: https://bugs.launchpad.net/neutron/+bug/1785848 - Neutron server producing tracebacks with 'L3RouterPlugin' object has no attribute 'is_distributed_router' when DVR is enabled - Fix merged https://review.openstack.org/#/c/589573 https://bugs.launchpad.net/neutron/+bug/1786213 - Metering agent: failed to run ip netns command - Fix merged https://review.openstack.org/#/c/590215/ Medium: https://bugs.launchpad.net/neutron/+bug/1786347 - Incorrect entry point of metering iptables driver - Fix merged https://review.openstack.org/#/c/590479 https://bugs.launchpad.net/neutron/+bug/1786169 - DVR: Missing fixed_ips info for IPv6 subnets - Proposed fix at https://review.openstack.org/#/c/590157 https://bugs.launchpad.net/neutron/+bug/1786413 - Cannot load neutron_fwaas.conf by neutron-api - Proposed fix at https://review.openstack.org/590656 https://bugs.launchpad.net/neutron/+bug/1786272 - Connection between two virtual routers does not work with DVR - In discussion (limitation or real issue) Low: https://bugs.launchpad.net/neutron/+bug/1786472 - Scenario test_connectivity_min_max_mtu fails when cirros is used - Fix merged https://review.openstack.org/#/c/590763 Wishlist: https://bugs.launchpad.net/neutron/+bug/1786226 - Use sqlalchemy baked query - Sample baked query at https://review.openstack.org/#/c/430973/2 already shows impressive performance improvements Incomplete: https://bugs.launchpad.net/neutron/+bug/1786047 - neutron-dhcp-agent is unable to set network namespaces - Issue happens on an openstack-ansible deployment with manual agent install on top. Additional details asked, but this is probably more a deployment issue than a real neutron bug https://bugs.launchpad.net/neutron/+bug/1786408 - IPsec shutdown and re-up the external-interface ,routing missing - a vpnaas bug, but on Kilo release. To confirm on a supported release? -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Tempest plugin for Neutron Stadium projects
That makes sense, thanks! I will add the topic to the next networking-sfc meeting On 2 January 2018 at 17:06, Miguel Lavalle wrote: > Hi Neutron community, > > During the last Neutron drivers meeting, we discussed whether all the > Neutron Stadium projects should have their Tempest code in > https://github.com/openstack/neutron-tempest-plugin/. It was decided to > allow Stadium projects to get their tests in the consolidated plugin but it > will not be a requirement. The assumption is that many projects might be > stretched in resources and we don't want to create more work for them. > > Best regards > > Miguel > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [stadium] Tempest plugin split goal for stadium projects
Hi neutrinos, to follow up on the community goal efffort to split tempest plugins in separate repos [1], I started the work for networking-sfc [2], aiming for a new "networking-sfc-tempest-plugin" repository. Armando had an interesting question that I am bringing to the wider audience: for stadium projects, should we create one tempest repo per project, or host all stadium tempest related tests in a single neutron repo [3]? In similar cases, we already currently have "common code" repos: neutron-lib for API, and python-neutronclient for OSC code. So what do you think? [1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html [2] https://review.openstack.org/#/c/510553/ [3] https://git.openstack.org/cgit/openstack/neutron-tempest-plugin -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc] pep8 failing
es/sfc/drivers/ovs/driver.py:721:13: N531 Log
>> messages require translation hints!
>> LOG.warning("Not found the flow classifier service plugin")
>> ^
>> ./networking_sfc/services/sfc/drivers/ovs/driver.py:983:13: N531 Log
>> messages require translation hints!
>> LOG.warning("Currently only support vxlan network")
>> ^
>> ./networking_sfc/services/sfc/drivers/ovs/driver.py:986:13: N531 Log
>> messages require translation hints!
>> LOG.warning("This port has not been binding")
>> ^
>> ./networking_sfc/services/sfc/drivers/ovs/driver.py:1107:13: N531 Log
>> messages require translation hints!
>> LOG.error("get_flowrules_by_host_portid failed")
>> ^
>> ./networking_sfc/services/sfc/drivers/ovs/rpc.py:44:9: N531 Log messages
>> require translation hints!
>> LOG.info('update_flowrules_status: %s', flowrules_status)
>> ^
>> ERROR: InvocationError:
>> '/home/vikash/python_src/networking-sfc/.tox/pep8/bin/flake8'
>> __
>> summary
>> ___
>> ERROR: pep8: commands failed
>>
>>
>> --
>> Regards,
>> Vikash
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Bernard Cafarelli
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking-sfc] Load distribution bug with OVS driver
Hi, this is a follow-up/summary of launchpad bug 1675289 [0]. From the original spec [1], with the OVS driver we should have groups witt the "hash" selection method, and for parameters source IP/port/protocol However this requires OpenFlow 1.5, so we actually have default selection method and no parameters customization. Selection is done on both source and destination [2], so in our case close to the "theorical" parameters. Additionally we can set "lb_fields" via API, but they are not currenly used in the driver. These also sound quite OVS-specific, not sure how other drivers handle it. Anyway, I outlined the possible change to fix this properly in the bug (if I got everything correctly). Feedback and comments welcome! [0] https://bugs.launchpad.net/networking-sfc/+bug/1675289 [1] https://github.com/openstack/networking-sfc/blob/master/doc/source/ovs_driver_and_agent_workflow.rst#group-table-flows [2] https://github.com/openvswitch/ovs/commit/1d1aae0b2f9a149bf74000d975fbf29d133cd9ca -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking-sfc] PTG notes
Hi, I will miss the next two IRC meetings, so here is a quick summary email of PTG topics of interest for networking-sfc in the Pike cycle. * Release, stable branching, stadium requirements For Ocata, neutron-lib patches are waiting for our stable branch creation (should be OK today?). The release itself is not as urgent, so we can still run some tests after merging the last open feature [0], and before tagging the release For Pike, stadium projects will synchronize releases with neutron [1] Except from more generic requirements, no new specific requirements to expect in this cycle * Tempest tests Two interesting items here: * Split tempest plugin repositories [2]: if agreed we will move the tempest plugin in a separate branchless repository (and proper configuration depending on features) * Refactor of tempest scenario base classes [3]: we will probably have to keep our copy of manager.py, and update to new API when it is ready * Python 3.5 support This is a project-wide goal for Pike, we have python3 unit tests already, but we should add a tempest/python3 check, and make it work (without forgetting the currently buggy multinode check) * neutron-lib hacking checks These are additional PEP8 checks we should enable as a neutron-lib consumer project. Some changes are underway [4], but we should enable these in networking-sfc * API updates Changes need to be advertised via a new extension (SFC graphs current review) * Push notifications This is in progress for Neutron [5], but can be nice for stadium projects too * Common classifier This probably deserves its separate topic, but we had an interesting session (possible consumers: networking-bpvpn, networking-sfc, FWaaS, QoS, Tap-as-a-Service, …) [6] The completed neutron etherpad is at [7], with Kevin's nice summary at [8] I leave it to other PTG attendees to correct/extend this list! [0] https://review.openstack.org/#/c/420339/ [1] https://review.openstack.org/#/c/437699/ [2] https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins [3] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112938.html [4] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112988.html [5] https://blueprints.launchpad.net/neutron/+spec/push-notifications [6] https://review.openstack.org/#/c/333993/ [7] https://etherpad.openstack.org/p/neutron-ptg-pike-final [8] http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday
+1 On 19 February 2017 at 00:32, Miguel Lavalle wrote: > +1 > > On Sat, Feb 18, 2017 at 11:44 AM, Korzeniewski, Artur > wrote: >> >> +1 >> >> >> >> From: Kevin Benton [mailto:ke...@benton.pub] >> Sent: Friday, February 17, 2017 8:19 PM >> To: openstack-dev@lists.openstack.org >> Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on >> Thursday >> >> >> >> Hi all, >> >> >> >> I'm organizing a Neutron social event for Thursday evening in Atlanta >> somewhere near the venue for dinner/drinks. If you're interested, please >> reply to this email with a "+1" so I can get a general count for a >> reservation. >> >> >> >> Cheers, >> >> Kevin Benton >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc]
Hi Michael, On 25 January 2017 at 06:50, Michael Gale wrote: > My biggest hurdle was around getting the devstack environment functioning, I > was following the steps here: > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining > > I think the issues are related to using Ubuntu 16.04 instead of Ubuntu 14.04 > and devstack now recommends 16.04. So the OVS steps seem out of place and in > my local.conf file I needed to set: > --snip-- > export SFC_UPDATE_OVS=False [...] > This could be related to my lack of experience with Devstack, also I was > concerned with having to set SFC_UPDATE_OVS=False in the configuration. Is > this affecting the underlying functionality of SFC. Ah, yes you did the right thing here, with newer distributions you do not need this, as the available OVS version is enough to run SFC (and in fact on 16.04 compilation would fail as you experienced). In fact this was removed on master and backported to stable/newton branch: https://git.openstack.org/cgit/openstack/networking-sfc/commit/?h=stable/newton&id=9256feca05db53bcfa656441b63d555874d3cf68 > Also the link to the Horizon add-on would be great. > > Thanks > Michael > > > On Tue, Jan 24, 2017 at 6:30 AM, Bernard Cafarelli > wrote: >> >> On 20 January 2017 at 00:06, Michael Gale wrote: >> > Hello, >> > >> > Are there updated install docs for sfc? The only install steps for a >> > testbed I can find are here and they seem outdated: >> > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining >> There is also a SFC chapter in the networking guide: >> http://docs.openstack.org/newton/networking-guide/config-sfc.html >> >> Which parts do you find outdated? Some references to Ubuntu/OVS >> versions may need a cleanup, but the design and API parts should still >> be OK >> (OSC client, SFC graph API, symmetric ports and other goodies are >> still under review and not yed merged) >> >> > Also from the conference videos there seems to be some Horizon menu / >> > screens that are available? >> Not for networking-sfc directly, but there is a SFC tab in the tacker >> horizon plugin (or will be, someone from the tacker team can confirm >> that) -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc]
On 20 January 2017 at 00:06, Michael Gale wrote: > Hello, > > Are there updated install docs for sfc? The only install steps for a > testbed I can find are here and they seem outdated: > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining There is also a SFC chapter in the networking guide: http://docs.openstack.org/newton/networking-guide/config-sfc.html Which parts do you find outdated? Some references to Ubuntu/OVS versions may need a cleanup, but the design and API parts should still be OK (OSC client, SFC graph API, symmetric ports and other goodies are still under review and not yed merged) > Also from the conference videos there seems to be some Horizon menu / > screens that are available? Not for networking-sfc directly, but there is a SFC tab in the tacker horizon plugin (or will be, someone from the tacker team can confirm that) -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] "Setup firewall filters only for required ports" bug
Hi neutrinos, I would like your feedback on the mentioned changeset in title[1] (yes, added since Liberty). With this patch, we (should) skip ports with port_security_enabled=False or with an empty list of security groups when processing added ports [2]. But we found multiple problems here * Ports create with port_security_enabled=False This is the original bug that started this mail: if the FORWARD iptables chain has a REJECT default policy/last rule, the traffic is still blocked[3]. There is also a launchpad bug with similar details [4] The problem here: these ports must not be skipped, as we add specific firewall rules to allow all traffic. These iptables rules have the following comment: "/* Accept all packets when port security is disabled. */" With the current code, any port created with port security will not have these rules (and updates do not work). I initially sent a patch to process these ports again [5], but there is more (as detailed by some in the launchpad bug) * Ports with no security groups, current code There is a bug in the current agent code [6]: even with no security groups, the check will return true as, the security_groups key exists in the port details (with value "[]"). So the port will not be skipped * Ports with no security groups, updated code Next step was to update checks (security groups list not empy, port security True or None), and test again. The port this time was skipped, but this showed up in openvswitch-agent.log: 2017-01-18 16:19:56.780 7458 INFO neutron.agent.linux.iptables_firewall [req-c49ca24f-1df8-40d7-8c48-6aab842ba34a - - - - -] Attempted to update port filter which is not filtered c2c58f8f-3b76-4c00-b792-f1726b28d2fc 2017-01-18 16:19:56.853 7458 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-c49ca24f-1df8-40d7-8c48-6aab842ba34a - - - - -] Configuration for devices up [u'c2c58f8f-3b76-4c00-b792-f1726b28d2fc'] and devices down [] completed. Which is the kind of logs we saw in the first bug report. So as an additional test, I tried to update this port, adding a security group. New log entries: 2017-01-18 17:36:53.164 7458 INFO neutron.agent.securitygroups_rpc [req-c49ca24f-1df8-40d7-8c48-6aab842ba34a - - - - -] Refresh firewall rules 2017-01-18 17:36:55.873 7458 INFO neutron.agent.linux.iptables_firewall [req-c49ca24f-1df8-40d7-8c48-6aab842ba34a - - - - -] Attempted to update port filter which is not filtered 0f2eea88-0e6a-4ea9-819c-e26eb692cb25 2017-01-18 17:36:58.587 7458 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-c49ca24f-1df8-40d7-8c48-6aab842ba34a - - - - -] Configuration for devices up [u'0f2eea88-0e6a-4ea9-819c-e26eb692cb25'] and devices down [] completed. And the iptables configuration did not change to show the newly allowed ports. So with a fixed check, wend up back in the same buggy situation as the first one. * Feedback So which course of action should we take? After checking these 3 cases out, I am in favour of reverting this commit entirely, as in its current state it does not help for ports without security groups, and breaks ports with port security disabled. Also, on the tests side, should we add more tests only using create calls (port_security tests mostly update an existing port)? How to make sure these iptables rules are correctly applied (the ping tests are not enough, especially if the host system does not reject packets by default)? [1] https://review.openstack.org/#/c/210321/ [2] https://github.com/openstack/neutron/blob/a66c27193573ce015c6c1234b0f2a1d86fb85a22/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1640 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1406263 [4] https://bugs.launchpad.net/neutron/+bug/1549443 [5] https://review.openstack.org/#/c/421832/ [6] https://github.com/openstack/neutron/blob/a66c27193573ce015c6c1234b0f2a1d86fb85a22/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1521 Thanks! -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers
On 10 January 2017 at 14:13, Duarte Cardoso, Igor wrote: > Hi networking-sfc, > > > > While working on the SFC Graphs patch, I observed the following limitation > when creating port-chains: http://paste.openstack.org/show/594387/. > > > > My objective was to have 2 port-chains acting on the same classification of > traffic but from different logical source ports – my expectation was that > there wouldn’t be any clash here. > > > > However, the flow-classifiers clash when they are associated to those 2 > different port-chains. > > > > The exception is raised in [1] and the attributes of the flow-classifier > being checked are in [2], where neither logical source port or logical > destination port are specified. > > > > Is there a specific reasoning behind this or can it be considered a bug? For > the SFC Graphs work, it’s important that this limitation be lifted – I’m > happy to submit a patch to correct it. > > Let me know your thoughts. > > > > [1] > https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259 > > [2] > https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159 This must be the theme for this week's networking-sfc topic then, I ended up hitting the same problem while anylyzing the tempest race condition failures [1]. Each test creates a new port to use for its port pair, and a new flow classifier. The flow classifier has the same parameters, except for the source logical port (the related port is used here). Apparently the test failure (a PortChainFlowClassifierInConflict exception) is caused by a flow classifier from a previous test conflicting with the new one. My thoughts here: this should indeed be allowed, and I think this restriction comes from an incorrect use of the *_conflict() functions [2]: we should use the full flowclassifier_conflict() instead of flowclassifier_basic_conflict(), as it adds logical port conflict check and is the "main" conflict check function. That is in fact the fix I just sent for review [3], local tempest runs went fine here. Feedback welcome! [1] https://bugs.launchpad.net/networking-sfc/+bug/1655618 [2] https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191 [3] https://review.openstack.org/#/c/419525/ -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] networking-sfc stable/newton branch broken
On 12 January 2017 at 03:28, Armando M. wrote: > Hi, > > Please have a look at [1]. The branch has been broken for some time now. > > Thanks, > Armando > > [1] > https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:stable/newton Indeed, it needs two fixes on the tempest gate: one is ready for backport [1], the other I am still working on [2] [1] https://review.openstack.org/#/c/418926/ [2] https://bugs.launchpad.net/networking-sfc/+bug/1655618 -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate
After some research, this review fixes the tempest failures: https://review.openstack.org/#/c/416503/1 (newer patchset has an unrelated fix for the functional tests gate) Multiple local tempest runs and gate rechecks all turned green with this fix. That is the good news part. The bad news is that I am still not sure on the root cause. The code that triggers the problems is: https://github.com/openstack/networking-sfc/blob/f5b52d5304796e44431b3874117aa0be91ed13d8/networking_sfc/services/sfc/drivers/ovs/db.py#L292 _get_port_detail() is just a wrapper on CommonDbMixin._get_by_id() from neutron, so is it triggered by two _model_query() calls in a row? Hoping someone can shed a light here, next time it may not be as an easy fix as removing an unused line On 22 December 2016 at 20:48, Mike Bayer wrote: > > On 12/20/2016 06:50 PM, Cathy Zhang wrote: >> >> Hi Bernard, >> >> Thanks for the email. I will take a look at this. Xiaodong has been >> working on tempest test scripts. >> I will work with Xiaodong on this issue. > > > I've added a comment to the issue which refers to upstream SQLAlchemy issue > https://bitbucket.org/zzzeek/sqlalchemy/issues/3803 as a potential > contributor, though looking at the logs linked from the issue it appears > that database deadlocks are also occurring which may also be a precursor > here. There are many improvements in SQLAlchemy 1.1 such that the > "rollback()" state should not be as susceptible to a corrupted database > connection as seems to be the case here. > > > > > >> >> Cathy >> >> >> -Original Message- >> From: Bernard Cafarelli [mailto:bcafa...@redhat.com] >> Sent: Tuesday, December 20, 2016 3:00 AM >> To: OpenStack Development Mailing List >> Subject: [openstack-dev] [networking-sfc] Intermittent database >> transaction issues, affecting the tempest gate >> >> Hi everyone, >> >> we have an open bug (thanks Igor for the report) on DB transaction issues: >> https://bugs.launchpad.net/networking-sfc/+bug/1630503 >> >> The thing is, I am seeing quite a few tempest gate failures that follow >> the same pattern: at some point in the test suite, the service gets >> warnings/errors from the DB layer (reentrant call, closed transaction, >> nested rollback, …), and all following tests fail. >> >> This affects both master and stable/newton branches (not many changes for >> now in the DB parts between these branches) >> >> Some examples: >> * https://review.openstack.org/#/c/400396/ failed with console log >> >> http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544 >> and service log >> >> http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301 >> * https://review.openstack.org/#/c/405391/ failed, >> >> http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323 >> and >> http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840 >> * another on master branch: https://review.openstack.org/#/c/411194/ >> with >> http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260 >> and >> http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310 >> >> I took a look at the errors, but only found old-and-apparently-fixed >> pymysql bugs, and suggestions like: >> * >> http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar >> * https://review.openstack.org/#/c/230481/ >> Not really my forte, so if someone could take a look at these logs and fix >> the problem, it would be great! Especially with the upcoming multinode >> tempest gate >> >> Thanks, >> -- >> Bernard Cafarelli >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __ >> OpenStack Development Mailin
[openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate
Hi everyone, we have an open bug (thanks Igor for the report) on DB transaction issues: https://bugs.launchpad.net/networking-sfc/+bug/1630503 The thing is, I am seeing quite a few tempest gate failures that follow the same pattern: at some point in the test suite, the service gets warnings/errors from the DB layer (reentrant call, closed transaction, nested rollback, …), and all following tests fail. This affects both master and stable/newton branches (not many changes for now in the DB parts between these branches) Some examples: * https://review.openstack.org/#/c/400396/ failed with console log http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544 and service log http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301 * https://review.openstack.org/#/c/405391/ failed, http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323 and http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840 * another on master branch: https://review.openstack.org/#/c/411194/ with http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260 and http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310 I took a look at the errors, but only found old-and-apparently-fixed pymysql bugs, and suggestions like: * http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar * https://review.openstack.org/#/c/230481/ Not really my forte, so if someone could take a look at these logs and fix the problem, it would be great! Especially with the upcoming multinode tempest gate Thanks, -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack][neutron-lbaas][octavia] About installing Devstack on Ubuntu
On 6 December 2016 at 13:12, Jens Rosenboom wrote: > 2016-12-06 7:16 GMT+01:00 Yipei Niu : >> Hi, All, >> >> I failed installing devstack on Ubuntu. The detailed info of local.conf and >> error is pasted in http://paste.openstack.org/show/591493/. >> >> BTW, python2.7 is installed in Ubuntu, and Python.h can be found under >> /usr/include/python2.7. >> >> stack@stack-VirtualBox:~$ locate Python.h >> >> /usr/include/python2.7/Python.h >> >> >> However, after I comment the configuration related to Neutron-LBaaS and >> Octavia in local.conf, it successes. >> >> Is it a bug? How to fix it? Look forward to your comments. Thanks. > > The failure does not happen on your local machine, but inside building > a disk-image for octavia. It seems to be a regression caused by > https://review.openstack.org/402250 and there is a bug report with a > proposed fix at https://bugs.launchpad.net/tripleo/+bug/1646977 Indeed, this is the reason it fails (breaking the image building part), Michael Johnson actually sent a few patches to fix it in Octavia: https://review.openstack.org/#/c/356590/ (octavia diff to remove dependency on tripleo-image-elements) https://review.openstack.org/#/c/406420/ (diskimage-builder fix to install python in pip-and-virtualenv element) https://review.openstack.org/#/c/406413/ (diskimage-builder fix to run sysctl on image, not host) -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel
+1, a specific channel would be nice! On 23 November 2016 at 13:09, Mohan Kumar wrote: > Yes , It will be good > > Thanks., > Mohankumar.N > > On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor > wrote: >> >> Hi networking-sfc’s leaders, devs and users, >> >> >> >> What do you think about having an IRC channel dedicated to >> networking-sfc’s discussions and sync? >> >> >> >> For the time being I have joined #networking-sfc @ freenode, and will >> stay online to keep it open. >> >> >> >> Best regards, >> >> Igor. >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona
+1 (and we are getting quite close to the 25 people headcount) On 17 October 2016 at 11:37, Daniel Alvarez Sanchez wrote: > Hi, > > +1 here > > On Mon, Oct 17, 2016 at 10:01 AM, Korzeniewski, Artur > wrote: >> >> +1 >> >> >> >> From: Oleg Bondarev [mailto:obonda...@mirantis.com] >> Sent: Monday, October 17, 2016 9:52 AM >> To: OpenStack Development Mailing List (not for usage questions) >> >> Subject: Re: [openstack-dev] [Neutron] Neutron team social event in >> Barcelona >> >> >> >> +1 >> >> >> >> On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar >> wrote: >> >> +1 >> >> >> >> On 14/10/2016 20:30, Miguel Lavalle wrote: >> >> Dear Neutrinos, >> >> I am organizing a social event for the team on Thursday 27th at 19:30. >> After doing some Google research, I am proposing Raco de la Vila, which >> is located in Poblenou: http://www.racodelavila.com/en/index.htm. The >> menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm >> >> It is easy to get there by subway from the Summit venue: >> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people >> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so >> we can get a final count. >> >> Here's some reviews: >> >> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html >> >> Cheers >> >> Miguel >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent
Thanks, the comment and function name led me to think it was supposed to only return the matching group. So I will keep current 1.3 version in the L2 agent extension then! On 20 September 2016 at 20:48, Cathy Zhang wrote: > Hi Bernard, > > Networking-sfc currently uses OF1.3. Although OF1.3 dumps all groups, > networking-sfc has follow-on filter code to select the info associated with > the specific group ID from the dump. So we are fine and let's keep it as > OF1.3. > > We can upgrade to OF1.5 when Neutron uses OF1.5. > > Thanks, > Cathy > > > -Original Message- > From: Bernard Cafarelli [mailto:bcafa...@redhat.com] > Sent: Tuesday, September 20, 2016 7:16 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS > agent > > In the OVSSfcAgent migration to a L2 agent extension review[1], Igor Duarte > Cardoso noticed a difference on the OpenFlow versions between a comment and > actual code. > In current code [2], we have: > # We need to dump-groups according to group Id, # which is a feature of > OpenFlow1.5 full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name > > Indeed, only OpenFlow 1.5 and later support dumping a specific group [3]. > Earlier versions of OpenFlow always dump all groups. > So current code will return all groups: > $ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1 OFPST_GROUP_DESC reply > (OF1.3) (xid=0x2): > > group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5) > > group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5) > $ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1 OFPST_GROUP_DESC reply > (OF1.5) (xid=0x2): > > group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5) > > This code behavior will not change in my extension rewrite, so this will > still have to be fixed. though I am not sure on the solution: > * We can use Openflow 1.5, but its support looks experimental? And Neutron > apparently only uses up to 1.4 (for OVS firewall extension) > * Method to dump a group can "grep" the group ID in the complete dump. > Not as efficient but works with OpenFlow 1.1+ > * Use another system to load balance across the port pairs? > > Thoughts? > In gerrit, I kept it set to 1.5 (no impact for now as this is still marked as > WIP) > > [1]: https://review.openstack.org/#/c/351789 > [2]: > https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py > [3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt > > -- > Bernard Cafarelli > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent
In the OVSSfcAgent migration to a L2 agent extension review[1], Igor Duarte Cardoso noticed a difference on the OpenFlow versions between a comment and actual code. In current code [2], we have: # We need to dump-groups according to group Id, # which is a feature of OpenFlow1.5 full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name Indeed, only OpenFlow 1.5 and later support dumping a specific group [3]. Earlier versions of OpenFlow always dump all groups. So current code will return all groups: $ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1 OFPST_GROUP_DESC reply (OF1.3) (xid=0x2): group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5) group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5) $ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1 OFPST_GROUP_DESC reply (OF1.5) (xid=0x2): group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5) This code behavior will not change in my extension rewrite, so this will still have to be fixed. though I am not sure on the solution: * We can use Openflow 1.5, but its support looks experimental? And Neutron apparently only uses up to 1.4 (for OVS firewall extension) * Method to dump a group can "grep" the group ID in the complete dump. Not as efficient but works with OpenFlow 1.1+ * Use another system to load balance across the port pairs? Thoughts? In gerrit, I kept it set to 1.5 (no impact for now as this is still marked as WIP) [1]: https://review.openstack.org/#/c/351789 [2]: https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py [3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] VxLAN UDP port configuration
Hi everyone, this is actually a follow-up from this previous thread and bug: http://lists.openstack.org/pipermail/openstack-dev/2015-March/059623.html https://bugs.launchpad.net/neutron/+bug/1373359 The OVS agent supports the "vxlan_udp_port" parameter in its configuration file (for Linux Bridge there is an open bug, default port is still used). But there is also a 'udp_port' column in 'ml2_vxlan_endpoints' table, that is currently not used. Before merging https://review.openstack.org/#/c/153891/25 (feedback welcome) that would actually update this table, should we keep specifc per-host port configuration? There was a loose agreement in the previous thread about going on with it, but using a common value everywhere is a good alternative. Most configurations would use the default port (either IANA or Linux), and can be set to another port if needed. But per-host configuration helps in mixed OVS/Linux Bridge setups. Thoughts? To see if we keep on with this code or just drop the column from database Thanks -- Bernard Cafarelli __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
