[Yahoo-eng-team] [Bug 1695394] Re: test_device_tagging tempest test fails with "mount: mounting /dev/sr0 on /mnt failed: Device or resource busy"
[Expired for tempest because there has been no activity for 60 days.]
** Changed in: tempest
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1695394
Title:
test_device_tagging tempest test fails with "mount: mounting /dev/sr0
on /mnt failed: Device or resource busy"
Status in OpenStack Compute (nova):
Expired
Status in tempest:
Expired
Bug description:
http://logs.openstack.org/56/468056/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-xenial/271b8fb/console.html
2017-06-02 15:20:49.385605 | Traceback (most recent call last):
2017-06-02 15:20:49.385655 | File "tempest/test.py", line 96, in wrapper
2017-06-02 15:20:49.385691 | return f(self, *func_args, **func_kwargs)
2017-06-02 15:20:49.385744 | File
"tempest/api/compute/servers/test_device_tagging.py", line 267, in
test_device_tagging
2017-06-02 15:20:49.385789 | self.ssh_client.exec_command('sudo mount
%s /mnt' % dev_name)
2017-06-02 15:20:49.385837 | File
"tempest/lib/common/utils/linux/remote_client.py", line 30, in wrapper
2017-06-02 15:20:49.385874 | return function(self, *args, **kwargs)
2017-06-02 15:20:49.385925 | File
"tempest/lib/common/utils/linux/remote_client.py", line 96, in exec_command
2017-06-02 15:20:49.385973 | return self.ssh_client.exec_command(cmd)
2017-06-02 15:20:49.386016 | File "tempest/lib/common/ssh.py", line
202, in exec_command
2017-06-02 15:20:49.386047 | stderr=err_data, stdout=out_data)
2017-06-02 15:20:49.386170 | tempest.lib.exceptions.SSHExecCommandFailed:
Command 'set -eu -o pipefail; PATH=$PATH:/sbin; sudo mount /dev/sr0 /mnt', exit
status: 255, stderr:
2017-06-02 15:20:49.386221 | mount: mounting /dev/sr0 on /mnt failed:
Device or resource busy
This is Pike code.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1695394/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1695394] Re: test_device_tagging tempest test fails with "mount: mounting /dev/sr0 on /mnt failed: Device or resource busy"
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]
** Changed in: nova
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1695394
Title:
test_device_tagging tempest test fails with "mount: mounting /dev/sr0
on /mnt failed: Device or resource busy"
Status in OpenStack Compute (nova):
Expired
Status in tempest:
Expired
Bug description:
http://logs.openstack.org/56/468056/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-xenial/271b8fb/console.html
2017-06-02 15:20:49.385605 | Traceback (most recent call last):
2017-06-02 15:20:49.385655 | File "tempest/test.py", line 96, in wrapper
2017-06-02 15:20:49.385691 | return f(self, *func_args, **func_kwargs)
2017-06-02 15:20:49.385744 | File
"tempest/api/compute/servers/test_device_tagging.py", line 267, in
test_device_tagging
2017-06-02 15:20:49.385789 | self.ssh_client.exec_command('sudo mount
%s /mnt' % dev_name)
2017-06-02 15:20:49.385837 | File
"tempest/lib/common/utils/linux/remote_client.py", line 30, in wrapper
2017-06-02 15:20:49.385874 | return function(self, *args, **kwargs)
2017-06-02 15:20:49.385925 | File
"tempest/lib/common/utils/linux/remote_client.py", line 96, in exec_command
2017-06-02 15:20:49.385973 | return self.ssh_client.exec_command(cmd)
2017-06-02 15:20:49.386016 | File "tempest/lib/common/ssh.py", line
202, in exec_command
2017-06-02 15:20:49.386047 | stderr=err_data, stdout=out_data)
2017-06-02 15:20:49.386170 | tempest.lib.exceptions.SSHExecCommandFailed:
Command 'set -eu -o pipefail; PATH=$PATH:/sbin; sudo mount /dev/sr0 /mnt', exit
status: 255, stderr:
2017-06-02 15:20:49.386221 | mount: mounting /dev/sr0 on /mnt failed:
Device or resource busy
This is Pike code.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1695394/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1702992] Re: get_diagnostics on a non-running instance raises unnecessary exception
[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.] ** Changed in: nova Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1702992 Title: get_diagnostics on a non-running instance raises unnecessary exception Status in OpenStack Compute (nova): Expired Bug description: Calling get_diagnostics on an instance that is shutdown either via CLI or API generates an exception, and adds an row to the nova.instance_fault table Reproduce: create an instance power it off run `nova diagnostics instance` Expected result: a simple error message returned to the user actual result: a new row in the nova.instance_faults table. a lot of text in nova-compute.log: 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher [req-1c775f02-887d-42b6-974d-129dbe73c7ce ffa01db44dc4435dbb613f50da552315 b1744f8baaa44d4f9762b9a7eaffc61f - - -] Exception during message handling: Instance 6ab6cc05-bebf-4bc2-95ac-7daf317125d6 in power_state 4. Cannot get_diagnostics while the instance is in this state. 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher executor_callback) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 129, in _do_dispatch 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/nova/exception.py", line 89, in wrapped 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher payload) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__ 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/nova/exception.py", line 72, in wrapped 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher return f(self, context, *args, **kw) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 378, in decorated_function 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher kwargs['instance'], e, sys.exc_info()) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__ 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 366, in decorated_function 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4089, in get_diagnostics 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher method='get_diagnostics') 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher InstanceInvalidState: Instance 6ab6cc05-bebf-4bc2-95ac-7daf317125d6 in power_state 4. Cannot get_diagnostics while the instance is in this state. 2017-07-07 19:00:12.301 23077 ERROR oslo_messaging.rpc.dispatcher 2017-07-07 19:00:12.305 23077 ERROR oslo_messaging._drivers.common [req-1c775f02-887d-42b6-974d-129dbe73c7ce ffa01db44dc4435dbb613f50da552315 b1744f8baaa44d4f9762b9a7eaffc61f - - -] Returning exception Instance 6ab6cc05-bebf-4bc2-95ac-7daf317125d6 in power_state 4. Cannot get_diagnostics while the instance is in this state. to caller 2017-07-07 19:00:12.306 23077 ERROR oslo_messaging._drivers.common [req-1c775f02-887d-42b6-974d-129dbe73c7ce ffa01db44dc4435dbb613f50da552315 b1744f8baaa44d4f9762b9a7eaffc61f - - -] ['Traceback (most recent call last):\n', ' File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply\nexecuto
[Yahoo-eng-team] [Bug 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong
** Changed in: networking-l2gw Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1259292 Title: Some tests use assertEqual(observed, expected) , the argument order is wrong Status in Astara: Fix Released Status in Bandit: Fix Released Status in Barbican: Fix Released Status in Blazar: Triaged Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in congress: Fix Released Status in daisycloud-core: New Status in Designate: Fix Released Status in OpenStack Backup/Restore and DR (Freezer): In Progress Status in Glance: Fix Released Status in glance_store: Fix Released Status in Higgins: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in networking-calico: Fix Released Status in networking-infoblox: In Progress Status in networking-l2gw: Fix Released Status in networking-sfc: Fix Released Status in quark: In Progress Status in OpenStack Compute (nova): Won't Fix Status in os-brick: Fix Released Status in PBR: Fix Released Status in pycadf: Fix Released Status in python-barbicanclient: Fix Released Status in python-ceilometerclient: Invalid Status in python-cinderclient: Fix Released Status in python-designateclient: Fix Committed Status in Glance Client: Fix Released Status in python-mistralclient: Fix Released Status in python-solumclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Rally: In Progress Status in Sahara: Fix Released Status in Solum: Fix Released Status in sqlalchemy-migrate: In Progress Status in SWIFT: In Progress Status in tacker: Fix Committed Status in tempest: Invalid Status in zaqar: Fix Released Bug description: The test cases will produce a confusing error message if the tests ever fail, so this is worth fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/astara/+bug/1259292/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716561] [NEW] feature of qos-detailed-reporting-of-available-rules is invalid in pike version
Public bug reported: Similar with bug https://bugs.launchpad.net/neutron/+bug/1716558, According to http://specs.openstack.org/openstack/neutron-specs/specs/pike/qos-detailed-reporting-of-available-rules.html, we should get details of every available rule type with different drivers in pike version. but it doesn't work. (1)neutron version root@ubuntudbs:/etc/neutron/plugins/ml2# vi /opt/stack/neutron/neutron.egg-info/PKG-INFO Metadata-Version: 1.1 Name: neutron Version: 11.0.0.0rc2.dev122 Summary: OpenStack Networking Home-page: https://docs.openstack.org/neutron/latest/ (2)the driver informations is missing in the result. root@ubuntudbs:/etc/neutron/plugins/ml2# openstack network qos rule type list +-+ | Type| +-+ | dscp_marking| | bandwidth_limit | +-+ root@ubuntudbs:/etc/neutron/plugins/ml2# ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716561 Title: feature of qos-detailed-reporting-of-available-rules is invalid in pike version Status in neutron: New Bug description: Similar with bug https://bugs.launchpad.net/neutron/+bug/1716558, According to http://specs.openstack.org/openstack/neutron-specs/specs/pike/qos-detailed-reporting-of-available-rules.html, we should get details of every available rule type with different drivers in pike version. but it doesn't work. (1)neutron version root@ubuntudbs:/etc/neutron/plugins/ml2# vi /opt/stack/neutron/neutron.egg-info/PKG-INFO Metadata-Version: 1.1 Name: neutron Version: 11.0.0.0rc2.dev122 Summary: OpenStack Networking Home-page: https://docs.openstack.org/neutron/latest/ (2)the driver informations is missing in the result. root@ubuntudbs:/etc/neutron/plugins/ml2# openstack network qos rule type list +-+ | Type| +-+ | dscp_marking| | bandwidth_limit | +-+ root@ubuntudbs:/etc/neutron/plugins/ml2# To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716561/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716558] [NEW] feature of quato counts is invalid in pike version
Public bug reported: I have installed the pike version by devstack. According to https://docs.openstack.org/releasenotes/neutron/pike.html,Implements a new extension, quota_details which extends existing quota API to show detailed information for a specified tenant. The new API shows details such as limits, used, reserved. but the quota counts is still the old infomation on my new pike version,I don't know why? (1)neutron version root@ubuntudbs:/etc/neutron/plugins/ml2# vi /opt/stack/neutron/neutron.egg-info/PKG-INFO Metadata-Version: 1.1 Name: neutron Version: 11.0.0.0rc2.dev122 Summary: OpenStack Networking Home-page: https://docs.openstack.org/neutron/latest/ (2)quota infomation for network root@ubuntudbs:/etc/neutron/plugins/ml2# openstack quota list --network +--+--+--+---+---+-+-+--+-+--+ | Project ID | Floating IPs | Networks | Ports | RBAC Policies | Routers | Security Groups | Security Group Rules | Subnets | Subnet Pools | +--+--+--+---+---+-+-+--+-+--+ | 7b78e24f23c840ee952125077b2eb249 | 50 | 100 | 1000 | 10 | 10 | 10 | 100 | 100 | -1 | +--+--+--+---+---+-+-+--+-+--+ root@ubuntudbs:/etc/neutron/plugins/ml2# ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716558 Title: feature of quato counts is invalid in pike version Status in neutron: New Bug description: I have installed the pike version by devstack. According to https://docs.openstack.org/releasenotes/neutron/pike.html,Implements a new extension, quota_details which extends existing quota API to show detailed information for a specified tenant. The new API shows details such as limits, used, reserved. but the quota counts is still the old infomation on my new pike version,I don't know why? (1)neutron version root@ubuntudbs:/etc/neutron/plugins/ml2# vi /opt/stack/neutron/neutron.egg-info/PKG-INFO Metadata-Version: 1.1 Name: neutron Version: 11.0.0.0rc2.dev122 Summary: OpenStack Networking Home-page: https://docs.openstack.org/neutron/latest/ (2)quota infomation for network root@ubuntudbs:/etc/neutron/plugins/ml2# openstack quota list --network +--+--+--+---+---+-+-+--+-+--+ | Project ID | Floating IPs | Networks | Ports | RBAC Policies | Routers | Security Groups | Security Group Rules | Subnets | Subnet Pools | +--+--+--+---+---+-+-+--+-+--+ | 7b78e24f23c840ee952125077b2eb249 | 50 | 100 | 1000 | 10 | 10 | 10 | 100 | 100 | -1 | +--+--+--+---+---+-+-+--+-+--+ root@ubuntudbs:/etc/neutron/plugins/ml2# To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716558/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716551] [NEW] Install and configure (Ubuntu) in glance: Cannot parse the password with "@"
Public bug reported: Install and configure (Ubuntu) in glance: Cannot parse the password with "@" This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0.0rc2.dev25 on 'Wed Aug 23 03:33:04 2017, commit 9820166' SHA: 982016670fe908e5d7026714b115e63b7c31b46b Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1716551 Title: Install and configure (Ubuntu) in glance: Cannot parse the password with "@" Status in Glance: New Bug description: Install and configure (Ubuntu) in glance: Cannot parse the password with "@" This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0.0rc2.dev25 on 'Wed Aug 23 03:33:04 2017, commit 9820166' SHA: 982016670fe908e5d7026714b115e63b7c31b46b Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1716551/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714355] Re: Pecan missing emulated bulk create
Reviewed: https://review.openstack.org/499428 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fb76c4f57d7d1cb6e74602d24a166c5d173917e0 Submitter: Jenkins Branch:master commit fb76c4f57d7d1cb6e74602d24a166c5d173917e0 Author: Kevin Benton Date: Wed Aug 30 20:02:18 2017 -0700 Pecan: Add missing emulated bulk create method This adds the simple bulk emulation logic that was present in the old legacy controller for plugins that do not support bulk operations. Closes-Bug: #1714355 Change-Id: I4ff02b9c5c007847edd18ec4ad6794257dd79576 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714355 Title: Pecan missing emulated bulk create Status in neutron: Fix Released Bug description: Pecan is missing the emulated bulk create logic for core plugins that don't support the bulk methods. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714355/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714769] Re: quota_details is broken for CountableResource provided by plugins other than the core plugin
Reviewed: https://review.openstack.org/501410
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=07bfe6adb96ee0a88b9dd54d7e4b0bb684b63e3c
Submitter: Jenkins
Branch:master
commit 07bfe6adb96ee0a88b9dd54d7e4b0bb684b63e3c
Author: Ihar Hrachyshka
Date: Wed Sep 6 12:55:24 2017 -0700
CountableResource: try count/get functions for all plugins
It's of no guarantee that core plugin implements counter/getter function
for a CountableResource. Instead of just trying core plugin, try every
plugin registered in the directory.
To retain backwards compatibility, we also make sure that core plugin is
checked first.
Change-Id: I5245e217e1f44281f85febbdfaf873321253dc5d
Closes-Bug: #1714769
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1714769
Title:
quota_details is broken for CountableResource provided by plugins
other than the core plugin
Status in networking-midonet:
In Progress
Status in networking-ovn:
Fix Released
Status in neutron:
Fix Released
Bug description:
The neutron tempest API test -
neutron.tests.tempest.api.admin.test_quotas.QuotasTest.test_detail_quotas
calls the API - ""GET /v2.0/quotas/{tenant_id}/details" which is
failing with the below logs in the neutron server
INFO neutron.pecan_wsgi.hooks.translation [None
req-64308681-f568-4dea-961b-5c9de579ac7e admin admin] GET failed (client
error): The resource could not be found.
INFO neutron.wsgi [None req-64308681-f568-4dea-961b-5c9de579ac7e admin admin]
10.0.0.7 "GET /v2.0/quotas/ff5c5121117348df94aa181d3504375b/detail HTTP/1.1"
status: 404 len: 309 time: 0.0295429
ERROR neutron.api.v2.resource [None req-b1b677cd-73b1-435d-bcc4-845dfa713046
admin admin] details failed: No details.: AttributeError: 'Ml2Plugin' object
has no attribute 'get_floatingips'
ERROR neutron.api.v2.resource Traceback (most recent call last):
ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/resource.py", line 98, in resource
ERROR neutron.api.v2.resource result = method(request=request, **args)
ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/extensions/quotasv2_detail.py", line 56, in details
ERROR neutron.api.v2.resource self._get_detailed_quotas(request, id)}
ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/extensions/quotasv2_detail.py", line 46, in
_get_detailed_quotas
ERROR neutron.api.v2.resource resource_registry.get_all_resources(),
tenant_id)
ERROR neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py",
line 163, in wrapped
ERROR neutron.api.v2.resource return method(*args, **kwargs)
ERROR neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py",
line 93, in wrapped
ERROR neutron.api.v2.resource setattr(e, '_RETRY_EXCEEDED', True)
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
ERROR neutron.api.v2.resource self.force_reraise()
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb)
ERROR neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py",
line 89, in wrapped
ERROR neutron.api.v2.resource return f(*args, **kwargs)
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 150, in wrapper
ERROR neutron.api.v2.resource ectxt.value = e.inner_exc
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
ERROR neutron.api.v2.resource self.force_reraise()
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb)
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 138, in wrapper
ERROR neutron.api.v2.resource return f(*args, **kwargs)
ERROR neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py",
line 128, in wrapped
ERROR neutron.api.v2.resource LOG.debug("Retry wrapper got retriable
exception: %s", e)
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
ERROR neutron.api.v2.resource self.force_reraise()
ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb)
ERROR neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py",
line 124, in wrapped
ER
[Yahoo-eng-team] [Bug 1715525] Re: v3 openrc file is missing PROJECT_DOMAIN_NAME
Reviewed: https://review.openstack.org/501530 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2d2a562194d2d5792b91c156879c9494184cb3d2 Submitter: Jenkins Branch:master commit 2d2a562194d2d5792b91c156879c9494184cb3d2 Author: Sam Morrison Date: Thu Sep 7 12:12:18 2017 +1000 Set PROJECT_DOMAIN_NAME in generated v3 openrc Change-Id: I97435d2137b5bd74cd9f8ebfb927e4e28a0dc00a Closes-bug: 1715525 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1715525 Title: v3 openrc file is missing PROJECT_DOMAIN_NAME Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The generated v3 openrc file doesn't specify either PROJECT_DOMAIN_ID or PROJECT_DOMAIN_NAME. If your project isn't in the default domain then this openrc file won't work for you. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1715525/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716522] [NEW] StaleDataError deleting router interface
Public bug reported: Recently saw this error in the dvr-multinode grenade job: ERROR neutron.api.v2.resource [None req-efa49ab7-5bc4-49a4-9ede-e6f638f80004 admin admin] remove_router_interface failed: No details.: StaleDataError: DELETE statement on table 'standardattributes' expected to delete 1 row(s); 0 were matched. Please set confirm_deleted_rows=False within the mapper configuration to prevent this warning. [...] INFO neutron.wsgi [None req-efa49ab7-5bc4-49a4-9ede-e6f638f80004 admin admin] 10.210.34.251 "PUT /v2.0/routers/12dd139f-6d5f-437d-87bf-a75b6edf5125/remove_router_interface HTTP/1.1" status: 500 len: 363 time: 47.3295698 http://logs.openstack.org/43/500143/4/check/gate-grenade-dsvm-neutron- dvr-multinode-ubuntu-xenial- nv/710e31d/logs/screen-q-svc.txt.gz#_Sep_11_19_16_23_495551 I won't cut-paste the long backtrace. Kevin Benton looked and found the ML2 agent code on both agents was updating the port status once it received an update from the server, regardless if that status had changed, most likely triggering this error and filling both the q-agt and q-svc logs with lots of messages. https://review.openstack.org/#/c/502850/ test patch started. ** Affects: neutron Importance: High Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716522 Title: StaleDataError deleting router interface Status in neutron: Confirmed Bug description: Recently saw this error in the dvr-multinode grenade job: ERROR neutron.api.v2.resource [None req-efa49ab7-5bc4-49a4-9ede-e6f638f80004 admin admin] remove_router_interface failed: No details.: StaleDataError: DELETE statement on table 'standardattributes' expected to delete 1 row(s); 0 were matched. Please set confirm_deleted_rows=False within the mapper configuration to prevent this warning. [...] INFO neutron.wsgi [None req-efa49ab7-5bc4-49a4-9ede-e6f638f80004 admin admin] 10.210.34.251 "PUT /v2.0/routers/12dd139f-6d5f-437d-87bf-a75b6edf5125/remove_router_interface HTTP/1.1" status: 500 len: 363 time: 47.3295698 http://logs.openstack.org/43/500143/4/check/gate-grenade-dsvm-neutron- dvr-multinode-ubuntu-xenial- nv/710e31d/logs/screen-q-svc.txt.gz#_Sep_11_19_16_23_495551 I won't cut-paste the long backtrace. Kevin Benton looked and found the ML2 agent code on both agents was updating the port status once it received an update from the server, regardless if that status had changed, most likely triggering this error and filling both the q-agt and q-svc logs with lots of messages. https://review.openstack.org/#/c/502850/ test patch started. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716522/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714381] Re: pecan is missing some plugin sanity validation for sorting+pagination
Reviewed: https://review.openstack.org/499430 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=31dc80a0c22ae1cbacad1694f799cbdc4228cfd4 Submitter: Jenkins Branch:master commit 31dc80a0c22ae1cbacad1694f799cbdc4228cfd4 Author: Kevin Benton Date: Wed Aug 30 20:11:34 2017 -0700 Pecan: add plugin pagination/sorting validation This adds the validation to ensure that the plugin supports native sorting when native pagination is used. This patch doesn't add a unit test for this because it will be covered in the switch to pecan for the existing unit tests in I76dc23fb7b96d82b0da50285bd0aac76142e81e5 (which is how this bug was discovered). Closes-Bug: #1714381 Change-Id: I6443832357c91fe791853a374cdec11dd1f968ea ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714381 Title: pecan is missing some plugin sanity validation for sorting+pagination Status in neutron: Fix Released Bug description: The legacy controller was validating that enabled, native pagination was only set when the plugin actually supported native sorting. Pecan needs to do this same thing for parity. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714381/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468315] Re: horizon doesn't work well, when volumev2 endpoint doesn't exist
After re-reading, marking as invalid. As mrunge indicated, this is a
deployment issue. No application can be expected to be able to call a
service that is not registered in keystone,
** Changed in: horizon
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1468315
Title:
horizon doesn't work well, when volumev2 endpoint doesn't exist
Status in OpenStack Dashboard (Horizon):
Invalid
Bug description:
When volumev2 is deleted from keystone endpoint list, horizon fails,
many errors popping up:
A more detailed stacktrace is this:
2015-06-24 08:12:59,579 11778 ERROR horizon.tables.base Error while checking
action permissions.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 1260,
in _filter_action
return action._allowed(request, datum) and row_matched
File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line
136, in _allowed
self.allowed(request, datum))
File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/volumes/volumes/tables.py",
line 108, in allowed
limits = api.cinder.tenant_absolute_limits(request)
File "/usr/lib/python2.7/site-packages/horizon/utils/memoized.py", line 90,
in wrapped
value = cache[key] = func(*args, **kwargs)
File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/cinder.py",
line 547, in tenant_absolute_limits
limits = cinderclient(request).limits.get().absolute
File "/usr/lib/python2.7/site-packages/cinderclient/v2/limits.py", line 91,
in get
return self._get("/limits", "limits")
File "/usr/lib/python2.7/site-packages/cinderclient/base.py", line 149, in
_get
resp, body = self.api.client.get(url)
File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line 302,
in get
return self._cs_request(url, 'GET', **kwargs)
File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line 269,
in _cs_request
**kwargs)
File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line 239,
in request
**kwargs)
File "/usr/lib/python2.7/site-packages/requests/api.py", line 50, in request
response = session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 451, in
request
prep = self.prepare_request(req)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 382, in
prepare_request
hooks=merge_hooks(request.hooks, self.hooks),
File "/usr/lib/python2.7/site-packages/requests/models.py", line 304, in
prepare
self.prepare_url(url, params)
File "/usr/lib/python2.7/site-packages/requests/models.py", line 362, in
prepare_url
to_native_string(url, 'utf8')))
MissingSchema: Invalid URL '/limits': No schema supplied. Perhaps you meant
http:///limits?
2015-06-24 08:13:04,212 11777 WARNING openstack_dashboard.api.cinder Cinder
v2 requested but no 'volumev2' service type available in Keystone catalog.
2015-06-24 08:13:04,213 11777 WARNING horizon.exceptions Recoverable error:
Invalid URL '/snapshots/detail': No schema supplied. Perhaps you meant
http:///snapshots/detail?
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1468315/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1239762] Re: Tests only cover Keystone v3
v2 has long been deprecated. d-o-a tests v2. ** Changed in: horizon Status: In Progress => Won't Fix ** Changed in: horizon Importance: Medium => Undecided -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1239762 Title: Tests only cover Keystone v3 Status in OpenStack Dashboard (Horizon): Won't Fix Bug description: Although we support both Keystone v2 and v3, we only test with v3. There's no easy way to run the tests with both versions or run version-specific tests. This can cause issues at times, see e.g. https://review.openstack.org/#/c/51157/ when we expect Horizon to behave differently based on API active version but can't easily test it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1239762/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1258593] Re: horizon's nova api should cache extensions list
** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1258593 Title: horizon's nova api should cache extensions list Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Currently nova api code memoize's calls to get extensions from nova. But there is a cache hit only if request arg is the same. Since get extensions is called in many places and extensions are not dynamic, we should cache more aggressively regardless of request. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1258593/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1241709] Re: lbaas multiple instance interface
lbaas support has been excised from Horizon. ** Changed in: horizon Status: In Progress => Won't Fix ** Changed in: horizon Importance: Medium => Undecided -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1241709 Title: lbaas multiple instance interface Status in OpenStack Dashboard (Horizon): Won't Fix Bug description: If you have an instance with multiple ip's, there is no way to select which one to use when adding it as a member of a load balancer via horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1241709/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1590939] Re: Job dsvm-integration fails entirely due to the Firefox 47 had been released
Integration tests have been abandoned all together by Horizon. This no longer applies. ** Changed in: horizon Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1590939 Title: Job dsvm-integration fails entirely due to the Firefox 47 had been released Status in OpenStack Dashboard (Horizon): Won't Fix Bug description: Obviously, existing WebDriver doesn't work with it, see for example http://logs.openstack.org/25/322325/6/gate/gate-horizon-dsvm- integration/d3d4dbc/console.html Possible countermeasures are either using an older FF (quick hotfix), or switching to the new Marionette webdriver (preferrable solution, see https://developer.mozilla.org/en- US/docs/Mozilla/QA/Marionette/WebDriver ). See https://github.com/SeleniumHQ/selenium/issues/2110 for reference To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1590939/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1534495] Re: Some panels is not set proper policy rules
This was addressed by https://github.com/openstack/horizon/commit/43e9df85ab286ddee96e9cff97f551781baf70d1 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1534495 Title: Some panels is not set proper policy rules Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Panels listing of below are not set proper policy rules. These are only set a permission of service. Therefore if service is enable but a user don't have a privilege by policy.json, a user will be able to display its page but an API error will occur. I think we should address it like a "projects" panel. openstack_dashboard/dashboards/admin/aggregates/panel.py openstack_dashboard/dashboards/admin/defaults/panel.py openstack_dashboard/dashboards/admin/flavors/panel.py openstack_dashboard/dashboards/admin/hypervisors/panel.py openstack_dashboard/dashboards/admin/images/panel.py openstack_dashboard/dashboards/admin/info/panel.py openstack_dashboard/dashboards/admin/instances/panel.py openstack_dashboard/dashboards/admin/metadata_defs/panel.py openstack_dashboard/dashboards/admin/networks/panel.py openstack_dashboard/dashboards/admin/routers/panel.py openstack_dashboard/dashboards/admin/volumes/panel.py openstack_dashboard/dashboards/project/access_and_security/panel.py openstack_dashboard/dashboards/project/firewalls/panel.py openstack_dashboard/dashboards/project/images/panel.py openstack_dashboard/dashboards/project/instances/panel.py openstack_dashboard/dashboards/project/loadbalancers/panel.py openstack_dashboard/dashboards/project/network_topology/panel.py openstack_dashboard/dashboards/project/networks/panel.py openstack_dashboard/dashboards/project/ngimages/panel.py openstack_dashboard/dashboards/project/overview/panel.py openstack_dashboard/dashboards/project/routers/panel.py openstack_dashboard/dashboards/project/stacks/panel.py openstack_dashboard/dashboards/project/stacks/resource_types/panel.py To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1534495/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1626720] Re: integration tests: test_download_rc_v2_file fails with selenium.common.exceptions.NoSuchElementException
Horizon has abandoned integration tests all together. This no longer
applies.
** Changed in: horizon
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1626720
Title:
integration tests: test_download_rc_v2_file fails with
selenium.common.exceptions.NoSuchElementException
Status in OpenStack Dashboard (Horizon):
Won't Fix
Bug description:
openstack_dashboard.test.integration_tests.tests.test_credentials.TestDownloadRCFile.test_download_rc_v2_file
failed several times. This test is executed first, so most time might
be needed.
There are two failure patterns observed.
The one is 'AssertionError: False is not true' and the other is
selenium.common.exceptions.NoSuchElementException.
In both patterns, "root: INFO: X11 isn't installed. Should use xvfb to run
tests" message was observed.
I think this is always output and is not related to this failure directly,
but it looks useful when using logstash.
the following query looks fine.
message:"root: INFO: X11 isn't installed. Should use xvfb to run tests."
AND (build_name:"gate-horizon-dsvm-integration-current-ubuntu-xenial" OR
build_name:"gate-horizon-dsvm-integration-deprecated-ubuntu-xenial")
(a) AssertionError: False is not true
==
FAIL:
openstack_dashboard.test.integration_tests.tests.test_credentials.TestDownloadRCFile.test_download_rc_v2_file
--
_StringException: Traceback (most recent call last):
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_credentials.py",
line 56, in test_download_rc_v2_file
self.assertTrue(False)
File
"/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/unittest2/case.py",
line 702, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true
>> begin captured logging <<
root: INFO: X11 isn't installed. Should use xvfb to run tests.
- >> end captured logging << -
(b) selenium.common.exceptions.NoSuchElementException
==
ERROR:
openstack_dashboard.test.integration_tests.tests.test_credentials.TestDownloadRCFile.test_download_rc_v2_file
--
_StringException: Traceback (most recent call last):
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_credentials.py",
line 28, in setUp
super(TestDownloadRCFile, self).setUp()
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py",
line 307, in setUp
self.home_pg.change_project(self.HOME_PROJECT)
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/pages/basepage.py",
line 66, in change_project
self.topbar.user_dropdown_project.click_on_project(name)
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/bars.py",
line 59, in user_dropdown_project
src_elem = self._get_element(*self._user_dropdown_project_locator)
File
"/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/baseregion.py",
line 61, in _get_element
return self.src_elem.find_element(*locator)
File "/opt/stack/new/horizon/horizon/test/webdriver.py", line 40, in
find_element
web_el = super(WrapperFindOverride, self).find_element(by, value)
File
"/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 752, in find_element
'value': value})['value']
File
"/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 236, in execute
self.error_handler.check_response(response)
File
"/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/errorhandler.py",
line 192, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: {"method":"css selector","selector":".navbar-collapse >
ul.navbar-nav:first-child"}
Stacktrace:
at FirefoxDriver.prototype.findElementInternal_
(file:///tmp/tmpFRqPcW/extensions/fxdri...@googlecode.com/components/driver-component.js:10770)
at fxdriver.Timer.prototype.setTimeout/<.notify
(file:///tmp/tmpFRqPcW/extensions/fxdri...@googlecode.com/components/driver-component.js:625)
>> begin captured logging <<
root: INFO: X11 isn't installed. Should use xvfb to run tests.
---
[Yahoo-eng-team] [Bug 1634968] Re: User with member role could see the admin tab
Actually, it was backported to newton: https://review.openstack.org/#/c/407121/ ** Changed in: horizon Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1634968 Title: User with member role could see the admin tab Status in OpenStack Dashboard (Horizon): Fix Released Bug description: We have deploymented an OpenStack cloud with newton release code. In horizon we found that even the member user could see the admin tab in horizon. Admin tab should only been seen by the admin user in the cloud. And in mitaka we even have the limit that only cloud admin could see that admin tab. But this change https://github.com/openstack/horizon/commit/ce5fb26bf5f431f0cdaa6860a732338db868a8fb #diff-aff3bed89850c87f3629774f5a4599bcL23 breaks the previous behavior. We should revert this change to give user the right privilege. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1634968/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1302490] Re: Requirements fail to be synced in milestone-proposed
** Changed in: swift Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1302490 Title: Requirements fail to be synced in milestone-proposed Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: With our current process around openstack/requirements, no requirements sync is ever pushed to milestone-proposed branches. None is proposed until the openstack/requirements MP branch is created, and when it is, the propose-requirements job fails with: git review -t openstack/requirements milestone-proposed + OUTPUT='Had trouble running git log --color=auto --decorate --oneline milestone-proposed --not remotes/gerrit/milestone-proposed fatal: ambiguous argument '\''milestone-proposed'\'': unknown revision or path not in the working tree. Use '\''--'\'' to separate paths from revisions' See https://jenkins.openstack.org/job/propose-requirements- updates/153/console as an example (while it lasts) To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1302490/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1470625] Re: Mechanism to register and run all external neutron alembic migrations automatically
** Changed in: networking-l2gw Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470625 Title: Mechanism to register and run all external neutron alembic migrations automatically Status in devstack: Fix Released Status in networking-cisco: Fix Committed Status in networking-l2gw: Fix Released Status in neutron: Fix Released Bug description: For alembic migration branches that are out-of-tree, we need a mechanism whereby the external code can register its branches when it is installed, and then neutron will provide automation of running all installed external migration branches when neutron-db-manage is used for upgrading. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1470625/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1193112] Re: stack.sh fails with Swift-proxy failure and ECONNREFUSED excepction in g-api
This seems to have been resolved sometime in the last few years.
** Changed in: swift
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1193112
Title:
stack.sh fails with Swift-proxy failure and ECONNREFUSED excepction in
g-api
Status in devstack:
Won't Fix
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Object Storage (swift):
Invalid
Bug description:
Devstack repo was cloned on 6/19/13 on a new VM.
stack.sh fails with:
2013-06-20 15:52:51 Request returned failure status.
2013-06-20 15:52:51 500 Internal Server Error
2013-06-20 15:52:51 Failed to upload image
2013-06-20 15:52:51 (HTTP 500)
2013-06-20 15:52:51 ++ failed
Swift-proxy failed with:
scottda@june19devstack:~/devstack$ cd /opt/stack/swift &&
/opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v ||
touch "/opt/stack/status/stack/s-proxy.failure"
proxy-server Starting keystone auth_token middleware
proxy-server Using /var/cache/swift as cache directory for signing certificate
proxy-server signing_dir mode is 0755 instead of 0700
proxy-server Starting the S3 Token Authentication component
Traceback (most recent call last):
File "/opt/stack/swift/bin/swift-proxy-server", line 22, in
run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
File "/opt/stack/swift/swift/common/wsgi.py", line 249, in run_wsgi
loadapp(conf_path, global_conf={'log_name': log_name})
File "/opt/stack/swift/swift/common/wsgi.py", line 100, in wrapper
return f(conf_uri, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247,
in loadapp
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272,
in loadobj
return context.create()
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 207,
in invoke
app = filter(app)
File "/opt/stack/keystone/keystone/middleware/s3_token.py", line 215, in
auth_filter
return S3Token(app, conf)
File "/opt/stack/keystone/keystone/middleware/s3_token.py", line 65, in
__init__
self.http_client_class = environment.httplib.HTTPConnection
AttributeError: 'NoneType' object has no attribute 'HTTPConnection'
G-api.log:
2013-06-20 15:52:51.635 7682 ERROR glance.api.v1.upload_utils
[910a1b19-21d0-4986-bb73-8af880607700 180b7a81c47e428694f8038b3da203df
e89788e278a74e46b1a2169ed0ed057d] Failed to upload image
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils Traceback (most
recent call last):
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/glance/glance/api/v1/upload_utils.py", line 85, in
upload_data_to_store
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
image_meta['size'])
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/glance/glance/store/swift.py", line 329, in add
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
self._create_container_if_missing(location.container, connection)
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/glance/glance/store/swift.py", line 489, in
_create_container_if_missing
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
connection.head_container(container)
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/python-swiftclient/swiftclient/client.py", line 1095, in
head_container
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils return
self._retry(None, head_container, container)
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/python-swiftclient/swiftclient/client.py", line 1048, in _retry
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils rv =
func(self.url, self.token, *args, **kwargs)
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/python-swiftclient/swiftclient/client.py", line 567, in
head_container
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
conn.request(method, path, '', req_headers)
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/opt/stack/python-swiftclient/swiftclient/client.py", line 193, in
request_escaped
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
func(method, url, body=body, headers=headers or {})
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils File
"/usr/lib/python2.7/httplib.py", line 962, in request
2013-06-20 15:52:51.635 7682 TRACE glance.api.v1.upload_utils
self._send_request(method, url, bo
[Yahoo-eng-team] [Bug 1257435] Re: Chef does not run with all install types
Per the last comment, I am marking this fix released. If you are still having issues, make sure you are using the latest version of cloud-init and if so please file a new bug with details on the latest failure. ** Changed in: cloud-init (Ubuntu) Status: Confirmed => Fix Released ** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1257435 Title: Chef does not run with all install types Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: When using #cloud-config and a chef directive, the initial `chef- client` run only happens when install_type is set to "gems". Expected behavior: No matter the install_type, an initial `chef- client` run will execute. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: cloud-init 0.7.3-0ubuntu2 ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6 Uname: Linux 3.11.0-13-generic x86_64 ApportVersion: 2.12.5-0ubuntu2.1 Architecture: amd64 Date: Tue Dec 3 13:04:27 2013 MarkForUpload: True PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1257435/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1599936] Re: l2gw provider config prevents *aas provider config from being loaded
I don't think this is a bug since oslo config will gather and merge parameters such service_providers across multiple files. I'm setting this as "Invalid" ** Changed in: networking-l2gw Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1599936 Title: l2gw provider config prevents *aas provider config from being loaded Status in devstack: New Status in networking-l2gw: Invalid Status in neutron: In Progress Bug description: networking-l2gw devstack plugin stores its service_providers config in /etc/l2gw_plugin.ini and add --config-file for it. as a result, neutron-server is invoked like the following. /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/midonet/midonet.ini --config-file /etc/neutron/l2gw_plugin.ini it breaks *aas service providers because NeutronModule.service_providers finds l2gw providers in cfg.CONF.service_providers.service_provider and thus doesn't look at *aas service_providers config, which is in /etc/neutron/neutron_*aas.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1599936/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1177432] Re: [SRU] cloud-init archive template should match Ubuntu Server
** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1177432 Title: [SRU] cloud-init archive template should match Ubuntu Server Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: [SRU Justification] Ubuntu Cloud Images are inconsistent with desktop and bare-metal server installations since backports, restricted and multiverse are not enabled. This is effected via cloud-init that uses a template to select an in-cloud archive. [FIX] Make the cloud-init template match that of Ubuntu-server. [REGRESION] The potential for regression is low. However, all users will experience slower fetch times on apt-get updates especially on slower or high latency networks. [TEST] 1. Build image from -proposed 2. Boot up image 3. Confirm that "sudo apt-get update" pulls in backports, restricted and multiverse. Backports are currently not enabled in the cloud-init template. This is needed in order to get the backport kernels on cloud images. Related bugs: * bug 997371: Create command to add "multiverse" and "-backports" to apt sources * bug 1513529: cloud image built-in /etc/apt/sources.list needs updating To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1177432/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716489] [NEW] [RFE] Implement Gluon as Neutron Service Plugin
Public bug reported: (1) Refactor current Gluon code to fit into a Neutron Service Plugin * Refactor API generator * Refactor database to reuse Neutron's database - this means that the tables are added to the Neutron DB space as service plugins would do, potentially with relationship to Neutron's own objects, but would still come from our API description (2) Two additional tasks that are also related to Neutron - optional for the first pass * optional "network" in Neutron, i.e. when creating a port, it doesn't need to attach to a network - https://bugs.launchpad.net/neutron/+bug/1664461 * new "network type" attribute - https://bugs.launchpad.net/neutron/+bug/1664466 (3) Coding to experiment it (4) Open questions: * Do we keep current "gluon" repo or create a new repo e.g. "networking-gluon" - Assume we go "networking-gluon" route for Gluon 2.x (Neutron Service Plugin), and keep "gluon" repo for Gluon 1.x (Extended ML2 Plugin). * Implement it as "Service Plugin" generator, or just a "Service Plugin"? - subject to initial experiment - preference is to make 'gluon' a library for implementing service plugins. The question is how to get a service plugin to require an API file and minimal extra code when implemented on the gluon framework. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716489 Title: [RFE] Implement Gluon as Neutron Service Plugin Status in neutron: New Bug description: (1) Refactor current Gluon code to fit into a Neutron Service Plugin * Refactor API generator * Refactor database to reuse Neutron's database - this means that the tables are added to the Neutron DB space as service plugins would do, potentially with relationship to Neutron's own objects, but would still come from our API description (2) Two additional tasks that are also related to Neutron - optional for the first pass * optional "network" in Neutron, i.e. when creating a port, it doesn't need to attach to a network - https://bugs.launchpad.net/neutron/+bug/1664461 * new "network type" attribute - https://bugs.launchpad.net/neutron/+bug/1664466 (3) Coding to experiment it (4) Open questions: * Do we keep current "gluon" repo or create a new repo e.g. "networking-gluon" - Assume we go "networking-gluon" route for Gluon 2.x (Neutron Service Plugin), and keep "gluon" repo for Gluon 1.x (Extended ML2 Plugin). * Implement it as "Service Plugin" generator, or just a "Service Plugin"? - subject to initial experiment - preference is to make 'gluon' a library for implementing service plugins. The question is how to get a service plugin to require an API file and minimal extra code when implemented on the gluon framework. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716489/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1590608] Re: Services should use http_proxy_to_wsgi middleware
** Changed in: cloudkitty Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1590608 Title: Services should use http_proxy_to_wsgi middleware Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in cloudkitty: Fix Released Status in congress: New Status in OpenStack Backup/Restore and DR (Freezer): Fix Released Status in Glance: Fix Released Status in Gnocchi: Fix Released Status in OpenStack Heat: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: Fix Released Status in neutron: Fix Released Status in Panko: Fix Released Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in senlin: Fix Released Status in OpenStack DBaaS (Trove): Fix Released Bug description: It's a common problem when putting a service behind a load balancer to need to forward the Protocol and hosts of the original request so that the receiving service can construct URLs to the loadbalancer and not the private worker node. Most services have implemented some form of secure_proxy_ssl_header = HTTP_X_FORWARDED_PROTO handling however exactly how this is done is dependent on the service. oslo.middleware provides the http_proxy_to_wsgi middleware that handles these headers and the newer RFC7239 forwarding header and completely hides the problem from the service. This middleware should be adopted by all services in preference to their own HTTP_X_FORWARDED_PROTO handling. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1590608/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716243] Re: gw_port not persistent in session for expire call
Reviewed: https://review.openstack.org/502331
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=4d228320921fbb74d8e5c88c860099fc298a88fc
Submitter: Jenkins
Branch:master
commit 4d228320921fbb74d8e5c88c860099fc298a88fc
Author: Kevin Benton
Date: Sun Sep 10 08:59:23 2017 -0700
Remove gw_port expire call
This was initially added as part of the patch here:
I09e8a694cdff7f64a642a39b45cbd12422132806
However, it doesn't serve a purpose anymore because nothing
references the gateway port DB object before it is deleted.
Closes-Bug: #1716243
Change-Id: I87b614f8aef73aab8b5dd8217c99db1fe3ade742
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1716243
Title:
gw_port not persistent in session for expire call
Status in neutron:
Fix Released
Bug description:
occasional functional failure. Example:
http://logs.openstack.org/33/499433/4/gate/gate-neutron-dsvm-
functional-ubuntu-xenial/3cc7baf/testr_results.html.gz
Traceback (most recent call last):
File "neutron/tests/base.py", line 118, in func
return f(self, *args, **kwargs)
File
"neutron/tests/functional/services/l3_router/test_l3_dvr_ha_router_plugin.py",
line 391, in test_dvr_ha_router_create_attach_internal_external_detach_delete
self._clear_external_gateway(router)
File
"neutron/tests/functional/services/l3_router/test_l3_dvr_ha_router_plugin.py",
line 320, in _clear_external_gateway
{'router': {l3.EXTERNAL_GW_INFO: {}}})
File "neutron/db/extraroute_db.py", line 65, in update_router
context, id, router)
File "neutron/db/l3_db.py", line 1844, in update_router
id, router)
File "neutron/db/api.py", line 162, in wrapped
return method(*args, **kwargs)
File "neutron/db/api.py", line 92, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 88, in wrapped
return f(*args, **kwargs)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_db/api.py",
line 150, in wrapper
ectxt.value = e.inner_exc
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_db/api.py",
line 138, in wrapper
return f(*args, **kwargs)
File "neutron/db/api.py", line 127, in wrapped
LOG.debug("Retry wrapper got retriable exception: %s", e)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 123, in wrapped
return f(*dup_args, **dup_kwargs)
File "neutron/db/l3_db.py", line 275, in update_router
self._update_router_gw_info(context, id, gw_info)
File "neutron/db/l3_gwmode_db.py", line 69, in _update_router_gw_info
context, router_id, info, router=router)
File "neutron/db/l3_db.py", line 506, in _update_router_gw_info
network_id)
File "neutron/db/l3_db.py", line 425, in _delete_current_gw_port
self._delete_router_gw_port_db(context, router)
File "neutron/db/l3_db.py", line 443, in _delete_router_gw_port_db
context.session.expire(gw_port)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
line 1533, in expire
self._expire_state(state, attribute_names)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
line 1536, in _expire_state
self._validate_persistent(state)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
line 1976, in _validate_persistent
state_str(state))
sqlalchemy.exc.InvalidRequestError: Instance '' is
not persistent within this Session
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1716243
[Yahoo-eng-team] [Bug 1715734] Re: Gratuitous ARP for floating IPs not so gratuitous
** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1715734 Title: Gratuitous ARP for floating IPs not so gratuitous Status in neutron: Invalid Bug description: OpenStack Release: Newton OS: Ubuntu 16.04 LTS When working in an environment with multiple application deployments that build up/tear down routers and floating ips, it has been observed that connectivity to new instances using recycled floating IPs may be impacted. In this environment, the external provider network is connected to a Cisco Nexus 7010 with a default arp cache timeout of 1500 seconds. We have observed that the L3 agent is sending out the following arpings when floating IPs are assigned: 2017-09-07 16:57:17.396 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-A', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.36'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 2017-09-07 16:57:19.644 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-U', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.29'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 2017-09-07 16:57:19.913 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-U', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.44'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 Here's the respective packet capture: 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.36 tell 172.29.77.39, length 28 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.29 tell 172.29.77.39, length 28 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.44 tell 172.29.77.39, length 28 The source address in all of those ARP requests is 172.29.77.39 - the IP primary address on the qg interface. The ARP entry for the recycled floating IPs on the Nexus is not being refreshed and remains stale. For the gratuitous ARP to be successful, the source IP needs to be changed to the respective floating IP, so that both the source and destination IPs are the same. The following code change was made in ip_lib.py: FROM: arping_cmd = ['arping', arg, '-I', iface_name, '-c', 1, # Pass -w to set timeout to ensure exit if interface # removed while running '-w', 1.5, address] TO: arping_cmd = ['arping', arg, '-I', iface_name, '-c', 1, # Pass -w to set timeout to ensure exit if interface # removed while running '-w', 1.5, '-S', address, address] With that change in place, the following packet captures reflects the new behavior: 18:10:30.389966 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.36 tell 172.29.77.36, length 28 18:10:30.390068 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.29 tell 172.29.77.29, length 28 18:10:30.390143 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.44 tell 172.29.77.44, length 28 Since making the change, we have not had a failed deployment and all recycled floating IPs appear to be reachable immediately. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1715734/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1709774] Re: Multiple router_centralized_snat interfaces created during Heat deployment
Reviewed: https://review.openstack.org/494376 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8c3cb2e15b48f5e2b0c3d22550f00f3c7adc7f33 Submitter: Jenkins Branch:master commit 8c3cb2e15b48f5e2b0c3d22550f00f3c7adc7f33 Author: Swaminathan Vasudevan Date: Wed Aug 16 21:48:08 2017 -0700 DVR: Multiple csnat ports created when RouterPort table update fails When router interfaces are added to DVR router, if the router has gateway configured, then the internal csnat ports are created for the corresponding router interfaces. We have seen recently after the csnat port is created if the RouterPort table update fails, there is a DB retry that is happening and that retry operation is creating an additional csnat port. This additional port is not getting removed automatically when the router interfaces are deleted. This issue is seen when testing with a simple heat template as per the bug report. This patch fixes the issue by calling the RouterPort create with delete_port_on_error context. Change-Id: I916011f2200f02556ebb30bce30e349a8023602c Closes-Bug: #1709774 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1709774 Title: Multiple router_centralized_snat interfaces created during Heat deployment Status in OpenStack Heat: Invalid Status in neutron: Fix Released Bug description: While attempting to deploy the attached hot template I ran into a few issues: 1. Multiple router_centralized_snat interfaces are being created. 2. One router_centralized_snat interface is created, but it's Down. When Multiple interfaces are created the stack can't be deleted. I need to manually delete the additional ports that have been created before the stack can be deleted. I'm using Newton with OVS+DVR. I should state up front that the `depends_on` that are in the template are more of a last ditch effort than anything else, and are likely incorrect. However, without them the problem still exists. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1709774/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716448] [NEW] Enable GVRP for vlan interfaces with linuxbridge agent option
Public bug reported: GARP VLAN registration protocol (GVRP) exchanges network VLAN information to allow switches to dynamically forward frames for one or more VLANs. By enabling gvrp on vlan interfaces created by linuxbridge agent operators will be able to dynamically create and destroy vlan based tenant networks. No additional switch configuration or software defined networking is required and brings the features of linuxbridge more in line with openvswitch based clouds. This should be enabled via an option in the linuxbridge agent config; however, there are no serious consequences for having it wrongly enabled. The changes required in the agent are checking the option, if true append 'gvrp on' to the 'ip link add' command that creates the vlan interface. For example 'ip link add link bond0 name bond0.365 type vlan id 365 gvrp on' creates a sub interface for vlan 365 on interface bond0 with gvrp enabled. Adding this capability greatly simplifies switch configuration and deployment of linuxbridge based clouds with minimal impact. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716448 Title: Enable GVRP for vlan interfaces with linuxbridge agent option Status in neutron: New Bug description: GARP VLAN registration protocol (GVRP) exchanges network VLAN information to allow switches to dynamically forward frames for one or more VLANs. By enabling gvrp on vlan interfaces created by linuxbridge agent operators will be able to dynamically create and destroy vlan based tenant networks. No additional switch configuration or software defined networking is required and brings the features of linuxbridge more in line with openvswitch based clouds. This should be enabled via an option in the linuxbridge agent config; however, there are no serious consequences for having it wrongly enabled. The changes required in the agent are checking the option, if true append 'gvrp on' to the 'ip link add' command that creates the vlan interface. For example 'ip link add link bond0 name bond0.365 type vlan id 365 gvrp on' creates a sub interface for vlan 365 on interface bond0 with gvrp enabled. Adding this capability greatly simplifies switch configuration and deployment of linuxbridge based clouds with minimal impact. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716448/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716445] [NEW] Double breadcrumb on Angular Details pages
Public bug reported: The Angular Details pages have double breadcrumbs - one showing a breakdown of the URL, and the other is a back button. They should be combined, so that the URL breakdown (e.g. Images/) links to the previous panel too. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1716445 Title: Double breadcrumb on Angular Details pages Status in OpenStack Dashboard (Horizon): New Bug description: The Angular Details pages have double breadcrumbs - one showing a breakdown of the URL, and the other is a back button. They should be combined, so that the URL breakdown (e.g. Images/) links to the previous panel too. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1716445/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1623488] Re: Documentation needed to clarify how to configure auth_endpoint for image signing
** No longer affects: barbican -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1623488 Title: Documentation needed to clarify how to configure auth_endpoint for image signing Status in OpenStack Compute (nova): Confirmed Status in openstack-manuals: Opinion Bug description: Description === By default Barbican uses http://localhost:5000/v3 for the auth_endpoint (where keystone is). Users should know that this can be changed in nova.conf. This will solve the issue of Barbican being unable to connect to Keystone. Steps to reproduce == If keystone is not on localhost then Barbican will not being able to connect to Keystone. Also, using this documentation to create a signed image: https://github.com/openstack/glance/blob/master/doc/source/signature.rst Then booting the image using 'nova boot'. Note: verify_glance_signatures must be set to true in nova.conf Expected result === Barbican should connect to Keystone to authorize credentials when booting a signed image. Actual result = Barbican cannot connect to Keystone and booting a signed image fails. Environment === This is using the mitaka branch. This also happens in Glance: https://bugs.launchpad.net/glance/+bug/1620539 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1623488/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716431] [NEW] IP pool not displaying under certain conditions in Floating IPs tab
Public bug reported: Version: 9.1.2 Mitaka In ;Project > Compute > Access and Security; view in Mitaka dashboard, we found out that on Floating IPs tab, in the Pool column, you can only see name of the pool if there are floating IPs already associated with instances. I believe it is cause by this - https://github.com/openstack/horizon/blob/mitaka- eol/openstack_dashboard/dashboards/project/access_and_security/tabs.py#L121 . The for cycle populating pool_name attribute on IP is inside 'if attached_instance_ids' condition. We expect to see which pool floating IP came from before the association as it was in Liberty. So the pool_name attribute should be defined in for cycle outside this if condition. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1716431 Title: IP pool not displaying under certain conditions in Floating IPs tab Status in OpenStack Dashboard (Horizon): New Bug description: Version: 9.1.2 Mitaka In ;Project > Compute > Access and Security; view in Mitaka dashboard, we found out that on Floating IPs tab, in the Pool column, you can only see name of the pool if there are floating IPs already associated with instances. I believe it is cause by this - https://github.com/openstack/horizon/blob/mitaka- eol/openstack_dashboard/dashboards/project/access_and_security/tabs.py#L121 . The for cycle populating pool_name attribute on IP is inside 'if attached_instance_ids' condition. We expect to see which pool floating IP came from before the association as it was in Liberty. So the pool_name attribute should be defined in for cycle outside this if condition. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1716431/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1677469] Re: networking-sfc is breaking tacker CI
Fix released in Pike ** Changed in: networking-sfc Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1677469 Title: networking-sfc is breaking tacker CI Status in networking-sfc: Fix Released Status in neutron: Fix Committed Bug description: http://logs.openstack.org/44/448844/6/check/gate-tacker-dsvm- functional-ubuntu-xenial-nv/31f9ef1/logs/screen-q-agt.txt.gz 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp [req-8948a445-84d5-4cd1-8084-551b7b135dcf - -] Agent main thread died of an exception 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp Traceback (most recent call last): 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_ryuapp.py", line 40, in agent_main_wrapper 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp ovs_agent.main(bridge_classes) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 2168, in main 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp agent = OVSNeutronAgent(bridge_classes, cfg.CONF) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 208, in __init__ 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.init_extension_manager(self.connection) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/local/lib/python2.7/dist-packages/osprofiler/profiler.py", line 153, in wrapper 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp return f(*args, **kwargs) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 393, in init_extension_manager 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.agent_api) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/neutron/neutron/agent/agent_extensions_manager.py", line 55, in initialize 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp extension.obj.initialize(connection, driver_type) 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/networking-sfc/networking_sfc/services/sfc/agent/extensions/sfc.py", line 82, in initialize 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.sfc_driver.initialize() 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/networking-sfc/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py", line 96, in initialize 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self._clear_sfc_flow_on_int_br() 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/opt/stack/new/networking-sfc/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py", line 171, in _clear_sfc_flow_on_int_br 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.br_int.delete_group(group_id='all') 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp AttributeError: 'OVSIntegrationBridge' object has no attribute 'delete_group' 2017-03-30 04:24:18.839 10667 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1677469/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchp
[Yahoo-eng-team] [Bug 1672922] Re: iptables: stop 'fixing' kernel sysctl bridge firewalling knobs
Reviewed: https://review.openstack.org/501862 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=183c82b59a69a308aff13829a153460207aba8b6 Submitter: Jenkins Branch:master commit 183c82b59a69a308aff13829a153460207aba8b6 Author: Boden R Date: Thu Sep 7 14:16:22 2017 -0600 doc br_netfilter prereq for linux bridge This patch updates our install documentation to account for the fact that linux systems must have net.bridge sysctl knobs. Change-Id: I8b65e2ef22d57cd6c501f25a33af8c1900f20497 Closes-Bug: #1672922 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1672922 Title: iptables: stop 'fixing' kernel sysctl bridge firewalling knobs Status in neutron: Fix Released Bug description: https://review.openstack.org/436315 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit c1dfb53bf1db1fe65ba6a8ef64a0b30151ee5c03 Author: Ihar Hrachyshka Date: Sat Feb 11 12:50:04 2017 + iptables: stop 'fixing' kernel sysctl bridge firewalling knobs Those are different on different kernel versions, and have reasonable default values on all newer kernel versions, including RHEL. We nevertheless made devstack to set those in the past; now I propose to clean the code from neutron tree and leave it up to deployment tools to fix in an unlikely case the system has broken default values. Now that iptables firewall code does not trigger sysctl, we can also remove this filter from the corresponding rootwrap .filters file. DocImpact make sure deployment docs mention the expected sysctl knob values. Change-Id: Iabf61021c90b0536be274463d48fb5a572ecc023 Related-Bug: #1622914 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1672922/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1715734] Re: Gratuitous ARP for floating IPs not so gratuitous
Thanks, Brian. I confirmed that the other 'arping' package was being installed over iputils-arping post-deploy by another set of playbooks. The difference in behavior between the two packages is subtle and not enough to cause any outright errors, but will affect users in a negative way as described in the initial report. Feel free to close this bug, and thanks again for your help. ** No longer affects: openstack-ansible -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1715734 Title: Gratuitous ARP for floating IPs not so gratuitous Status in neutron: In Progress Bug description: OpenStack Release: Newton OS: Ubuntu 16.04 LTS When working in an environment with multiple application deployments that build up/tear down routers and floating ips, it has been observed that connectivity to new instances using recycled floating IPs may be impacted. In this environment, the external provider network is connected to a Cisco Nexus 7010 with a default arp cache timeout of 1500 seconds. We have observed that the L3 agent is sending out the following arpings when floating IPs are assigned: 2017-09-07 16:57:17.396 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-A', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.36'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 2017-09-07 16:57:19.644 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-U', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.29'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 2017-09-07 16:57:19.913 13048 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/openstack/venvs/neutron-r14.1.0/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-3429e5bc-b41b-46fb-9bef-6ec6ccf0d3b6', 'arping', '-U', '-I', 'qg-6582bfec-7d', '-c', '1', '-w', '1.5', '172.29.77.44'] create_process /openstack/venvs/neutron-r14.1.0/lib/python2.7/site-packages/neutron/agent/linux/utils.py:89 Here's the respective packet capture: 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.36 tell 172.29.77.39, length 28 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.29 tell 172.29.77.39, length 28 18:09:06.366085 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.44 tell 172.29.77.39, length 28 The source address in all of those ARP requests is 172.29.77.39 - the IP primary address on the qg interface. The ARP entry for the recycled floating IPs on the Nexus is not being refreshed and remains stale. For the gratuitous ARP to be successful, the source IP needs to be changed to the respective floating IP, so that both the source and destination IPs are the same. The following code change was made in ip_lib.py: FROM: arping_cmd = ['arping', arg, '-I', iface_name, '-c', 1, # Pass -w to set timeout to ensure exit if interface # removed while running '-w', 1.5, address] TO: arping_cmd = ['arping', arg, '-I', iface_name, '-c', 1, # Pass -w to set timeout to ensure exit if interface # removed while running '-w', 1.5, '-S', address, address] With that change in place, the following packet captures reflects the new behavior: 18:10:30.389966 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.36 tell 172.29.77.36, length 28 18:10:30.390068 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.29 tell 172.29.77.29, length 28 18:10:30.390143 fa:16:3e:99:af:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 103, p 0, ethertype ARP, Request who-has 172.29.77.44 tell 172.29.77.44, length 28 Since making the change, we have not had a failed deployment and all recycled floating IPs appear to be reachable immediately. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1715734/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : ya
[Yahoo-eng-team] [Bug 1716403] [NEW] Install and configure (Ubuntu) in glance: "create a database" section is missing
Public bug reported: Only the first step of "create a database" is shown in https://docs.openstack.org/glance/pike/install/install-ubuntu.html This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [x] I have a fix to the document that I can paste below: The following commands should be added: ... (in "create a database" section) 2. Create the glance database: MariaDB [(none)]> CREATE DATABASE glance 3. Grant proper access to the glance database: MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \ IDENTIFIED BY 'GLANCE_DBPASS'; MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \ IDENTIFIED BY 'GLANCE_DBPASS'; Replace GLANCE_DBPASS with a suitable password. 4. Exit the database access client. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0.0rc2.dev25 on 'Wed Aug 23 03:33:04 2017, commit 9820166' SHA: 982016670fe908e5d7026714b115e63b7c31b46b Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1716403 Title: Install and configure (Ubuntu) in glance: "create a database" section is missing Status in Glance: New Bug description: Only the first step of "create a database" is shown in https://docs.openstack.org/glance/pike/install/install-ubuntu.html This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [x] I have a fix to the document that I can paste below: The following commands should be added: ... (in "create a database" section) 2. Create the glance database: MariaDB [(none)]> CREATE DATABASE glance 3. Grant proper access to the glance database: MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \ IDENTIFIED BY 'GLANCE_DBPASS'; MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \ IDENTIFIED BY 'GLANCE_DBPASS'; Replace GLANCE_DBPASS with a suitable password. 4. Exit the database access client. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0.0rc2.dev25 on 'Wed Aug 23 03:33:04 2017, commit 9820166' SHA: 982016670fe908e5d7026714b115e63b7c31b46b Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1716403/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716401] [NEW] FWaaS: Ip tables rules do not get updated in case of distributed virtual routers (DVR)
Public bug reported: I have set up an HA/DVR deployment of OpenStack Pike on Ubuntu 16.04 and enabled FWaaS v1. After applying the Fix from Bug #1715395, firewall rules get created in case of HA/DVR, but updates do not have any effect, e.g. when you disassociate a firewall from a distributed router. Use Case: 1. Set up an HA/DVP deployment of OpenStack Pike. 2. Create a firewall rule. $ neutron firewall-rule-create --name test-rule --protocol icmp --action reject Created a new firewall_rule: ++--+ | Field | Value| ++--+ | action | reject | | description| | | destination_ip_address | | | destination_port | | | enabled| True | | firewall_policy_id | | | id | 6c2516cb-b69d-46b6-958e-e47c1cf1709e | | ip_version | 4| | name | test-rule| | position | | | project_id | ed2d2efd86dd40e7a45491d8502318d3 | | protocol | icmp | | shared | False| | source_ip_address | | | source_port| | | tenant_id | ed2d2efd86dd40e7a45491d8502318d3 | ++--+ 3. Create a firewall policy. $ neutron firewall-policy-create --firewall-rules test-rule test-policy Created a new firewall_policy: ++--+ | Field | Value| ++--+ | audited| False| | description| | | firewall_rules | 6c2516cb-b69d-46b6-958e-e47c1cf1709e | | id | 53a8d733-e81c-4113-9354-d40b5b426e00 | | name | test-policy | | project_id | ed2d2efd86dd40e7a45491d8502318d3 | | shared | False| | tenant_id | ed2d2efd86dd40e7a45491d8502318d3 | ++--+ 4. Create a firewall. $ neutron firewall-create --name test-firewall test-policy Created a new firewall: ++--+ | Field | Value| ++--+ | admin_state_up | True | | description| | | firewall_policy_id | 53a8d733-e81c-4113-9354-d40b5b426e00 | | id | a468caca-c555-4f89-adbc-bcdbb06a3fca | | name | test-firewall| | project_id | ed2d2efd86dd40e7a45491d8502318d3 | | router_ids | | | status | INACTIVE | | tenant_id | ed2d2efd86dd40e7a45491d8502318d3 | ++--+ 5. Assign the firewall to a distributed router. $ neutron firewall-update --router demo-router test-firewall Updated firewall: test-firewall 6. Spawn a virtual machine and assign a floating ip. 7. Check namespaces on the compute node hosting the virtual machine. $ ip netns fip-4a3959c3-b011-4bd0-8f4f-f405be92d9ac qrouter-09a379b5-907f-4e3e-b29a-8701b82f2641 8. Check ip tables rules in the router's namespace. $ ip netns exec qrouter-09a379b5-907f-4e3e-b29a-8701b82f2641 iptables -n -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 neutron-l3-agent-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 40 packets, 2400 bytes) pkts bytes target prot opt in out source destination 185 11100 neutron-filter-top all -- * * 0.0.0.0/0 0.0.0.0/0 185 11100 neutron-l3-agent-FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 neutron-filter-top all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 neutron-l3-agent-OUTPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain neutron-filter-top (2 references) pkts bytes target prot opt in out source
[Yahoo-eng-team] [Bug 1716397] [NEW] OpenNebula network configuration is ignored for distros with predictable interface names.
Public bug reported: OpenNebula network configuration is provided in context with device identifiers in the form ETH[0-9] but with newer distros using predictable interface names this configuration is no longer applied and device MAC should be checked instead of the identifier. Even when providing matching device name, this information is not being correctly propagated by the OpenNebula data source to the other cloud- init modules ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1716397 Title: OpenNebula network configuration is ignored for distros with predictable interface names. Status in cloud-init: New Bug description: OpenNebula network configuration is provided in context with device identifiers in the form ETH[0-9] but with newer distros using predictable interface names this configuration is no longer applied and device MAC should be checked instead of the identifier. Even when providing matching device name, this information is not being correctly propagated by the OpenNebula data source to the other cloud-init modules To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1716397/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1537267] Re: release request for networking-sfc in Mitaka time frame
Cleaning bugs status: release is available ** Changed in: networking-sfc Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1537267 Title: release request for networking-sfc in Mitaka time frame Status in networking-sfc: Fix Released Status in neutron: Fix Released Bug description: Branch: stable/mitaka We also has stable/liberty branch for release against liberty branch code base and would like to release it too. The release of networking-sfc contains feature support for service function chaining. release version: 1.0.0 All code patches have been reviewed (open for review and collecting comments for a very long time) and merged. Test scripts have also been merged. In addition, comprehensive end-to-end integration testing within the same subnet and across different subnets with many different CLI combinations have been tested. The community project team has agreed that the codes are ready for release so that more people can give it a try and give input on future enhancement. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1537267/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714348] Re: pecan is missing some body validation logic from legacy API
Reviewed: https://review.openstack.org/499427 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=444f802012d30d912f300ad05cdf201b8c48f347 Submitter: Jenkins Branch:master commit 444f802012d30d912f300ad05cdf201b8c48f347 Author: Kevin Benton Date: Wed Aug 30 19:59:50 2017 -0700 Pecan: Add missing body validations This changes the pecan body validation to bring parity with the old legacy controller code. * If a body is present on POST/PUT, it must be a JSON dict * DELETEs to an item must not contain a body * A POST request to the standard collection controller must have resources in the body. Closes-Bug: #1714348 Change-Id: I1568285c28d227bacf038b3667466a20d3947ca9 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714348 Title: pecan is missing some body validation logic from legacy API Status in neutron: Fix Released Bug description: The legacy controller validated the following things that the pecan API is not. * delete requests have no body * the body must contain a resource or resources when POSTing to the general collection controller * All POSTed json must be a dict These gaps were discovered when switching the unit tests to use pecan instead of the old legacy API. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714348/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714388] Re: Pecan is missing the logic to hide authorization failures as 404s
Reviewed: https://review.openstack.org/499433 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fe8107a8179deca093463bbc95b6ba8b54915bf7 Submitter: Jenkins Branch:master commit fe8107a8179deca093463bbc95b6ba8b54915bf7 Author: Kevin Benton Date: Wed Aug 30 20:15:49 2017 -0700 Pecan: fix logic of hiding authZ failures as 404s Change [1] altered the behavior of the legacy API controller to do the sane thing and return an HTTP 403 instead of a 404 whenever a user got a policy authorization failure when trying to mutate a resource they have the permission to view. This carries the same logic over to the pecan API. This also adjusts the logic for GET requests to return 404s instead of 403s to match the resource hiding behavior of the old controller. 1. I7a5b0a9e89c8a71490dd74497794a52489f46cd2 Closes-Bug: #1714388 Change-Id: I9e0d288a42bc63c2927bebe9c581b83e6fbe010b ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714388 Title: Pecan is missing the logic to hide authorization failures as 404s Status in neutron: Fix Released Bug description: The pecan code is missing the logic to translate some of the authorization failures into 404s instead of 403's. https://github.com/openstack/neutron/blob/8d2c1bd88b14eefbea74c72f384cb9952e7ee62e/neutron/api/v2/base.py#L575-L585 https://github.com/openstack/neutron/blob/8d2c1bd88b14eefbea74c72f384cb9952e7ee62e/neutron/api/v2/base.py#L389-L393 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714388/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1716344] [NEW] Nova-API sometimes uses Keystone's public endpoint
Public bug reported:
I have setup a fresh HA deployment of OpenStack Pike on Ubuntu 16.04. I
recognized in the logs that Nova sometimes fails during vm creation with
the following exception:
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity
[req-6efab9e1-78f5-4e85-8247-686ff4f3568c dddfba8e02f746799a6408a523e6cd25
ed2d2efd86dd40e7a45491d8502318d3 - default default] Unable to contact keystone
to verify project_id: SSLError: SSL exception connecting to
https://os-cloud.mycompany.com:5000/v3/projects/ed2d2efd86dd40e7a45491d8502318d3:
("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate',
'certificate verify failed')],)",)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity Traceback (most
recent call last):
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity File
"/usr/lib/python2.7/dist-packages/nova/api/openstack/identity.py", line 42, in
verify_project_id
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity
raise_exc=False)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity File
"/usr/lib/python2.7/dist-packages/keystoneauth1/session.py", line 845, in get
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity return
self.request(url, 'GET', **kwargs)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity File
"/usr/lib/python2.7/dist-packages/positional/__init__.py", line 101, in inner
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity return
wrapped(*args, **kwargs)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity File
"/usr/lib/python2.7/dist-packages/keystoneauth1/session.py", line 703, in
request
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity resp =
send(**kwargs)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity File
"/usr/lib/python2.7/dist-packages/keystoneauth1/session.py", line 765, in
_send_request
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity raise
exceptions.SSLError(msg)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity SSLError: SSL
exception connecting to
https://os-cloud.mycompany.com:5000/v3/projects/ed2d2efd86dd40e7a45491d8502318d3:
("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate',
'certificate verify failed')],)",)
2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity
Keystone's public endpoint should only visible to external clients. All
internal OpenStack services should use the internalURL for
authentication purposes. I think my configuration is correct. The
"auth_url" point to Keystone's internal URL, whereas "auth_uri" points
to Keystone's public endpoint. The strange thing is, that sometimes
after a service restart, Nova uses the Keystone's internal URL and
sometimes the Keystone's public URL. I want to avoid https based
communication for the internal cloud services.
$ openstack endpoint list | grep keystone
| 00a22bfee72141ddadacd0e357161075 | RegionOne | keystone | identity
| True| internal | http://os-identity.mycompany.com:5000/v3
|
| 7178e534cb4e4c5e9a67066ff3e9c433 | RegionOne | keystone | identity
| True| public| https://os-cloud.mycompany.com:5000/v3
|
| f5ed3bba70274d7fa03f2ceaab96c3c9 | RegionOne | keystone | identity
| True| admin | http://os-identity.mycompany.com:35357/v3
|
nova.conf
...
[keystone_authtoken]
auth_type = password
auth_uri = http://os-cloud.mycompany.com:5000
auth_url = http://os-identity:35357
memcached_servers = os-memcache:11211
password = novapass
project_domain_name = default
project_name = service
user_domain_name = default
username = nova
...
Using the option "insecure = True" is a workaround to avoid that Nova
sometimes fails when the service uses Keystone's public https endpoint.
Can someone please have a look?
** Affects: nova
Importance: Undecided
Status: New
** Description changed:
I have setup a fresh HA deployment of OpenStack Pike on Ubuntu 16.04. I
recognized in the logs that Nova sometimes fails during vm creation with
the following exception:
- 2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity
[req-6efab9e1-78f5-4e85-8247-686ff4f3568c dddfba8e02f746799a6408a523e6cd25
ed2d2efd86dd40e7a45491d8502318d3 - default default] Unable to contact keystone
to verify project_id: SSLError: SSL exception connecting to
https://os-cloud.materna.com:5000/v3/projects/ed2d2efd86dd40e7a45491d8502318d3:
("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate',
'certificate verify failed')],)",)
+ 2017-09-11 09:31:28.909 5604 ERROR nova.api.openstack.identity
[req-6efab9e1-78f5-4e85-8247-686ff4f3568c dddfba8e02f746799a6408a523e6cd25
ed2d2efd86dd40e7a45491d8502318d3 - default default] Unable to contact keystone
to verify project_id: SSLError: SSL exception connecting to
https
[Yahoo-eng-team] [Bug 1716325] [NEW] failed to create an Instance with direct port, it reported "Timeout waiting for vif plugging callback for instance"
Public bug reported: Hi Guys: I failed to create an Instance with direct port,it reported "Timeout waiting for vif plugging callback for instance". version info: Ocata nova --version 7.1.1 libvirt+kvm Neutron with OpenVSwitch ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1716325 Title: failed to create an Instance with direct port,it reported "Timeout waiting for vif plugging callback for instance" Status in OpenStack Compute (nova): New Bug description: Hi Guys: I failed to create an Instance with direct port,it reported "Timeout waiting for vif plugging callback for instance". version info: Ocata nova --version 7.1.1 libvirt+kvm Neutron with OpenVSwitch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1716325/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
