[Yahoo-eng-team] [Bug 1694614] Re: Docs job on jenkins failing
Reviewed: https://review.openstack.org/469650 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4a1d951920e26287d849c6e670d1fff5789e261d Submitter: Jenkins Branch:master commit 4a1d951920e26287d849c6e670d1fff5789e261d Author: Ihar Hrachyshka Date: Wed May 31 13:41:30 2017 -0700 Switched to pyroute2.config.asyncio.asyncio_config To monkey patch socket module for pyroute2, we call eventlet_config. In recent releases of the library, this becomes deprecated. Instead, we should now use asyncio_config() to patch stdlib. Using the old path now triggers a warning. Our docs tox target (and gate job) considers all warnings as errors (this is because we pass -W to sphinx). We also import from neutron.tests.functional to generate one of our docs pages. Which all combined breaks our docs job. This patch fixes the warning, and the job. Change-Id: I7554327c9f09c85b52293240b23133eeadc90670 Closes-Bug: #1694614 ** 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/1694614 Title: Docs job on jenkins failing Status in neutron: Fix Released Bug description: I see failed gate-neutron-docs-ubuntu-xenial in many jobs since yesterday. It always fails with error like e.g. in http://logs.openstack.org/60/469260/2/check/gate-neutron-docs-ubuntu- xenial/e55b579/console.html#_2017-05-30_22_18_04_277430 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694614/+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 1694371] Re: test_stack_snapshot_restore failing intermittently
Actually looks like the vif is plugged successfully. This is where it starts: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-n-cpu.txt.gz?level=DEBUG#_May_28_04_09_48_125012 And this is where it says it was successful: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-n-cpu.txt.gz?level=DEBUG#_May_28_04_09_48_221125 And then it times out 5 minutes later: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-n-cpu.txt.gz?level=DEBUG#_May_28_04_14_48_559598 Looks like the port is plugged on the neutron side here: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-q-svc.txt.gz#_May_28_04_09_48_412466 But I don't see a network-vif-plugged event. I do see the network-vif- unplugged event 5 minutes later: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-q-svc.txt.gz#_May_28_04_14_50_528198 There was a network-vif-plugged event before though: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm-functional- convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-q-svc.txt.gz#_May_28_04_09_32_689843 I wonder if ^ is from the original spawn and then the 2nd vif plug is from the rebuild action, and that's why we don't get a network-vif- plugged event from neutron, because it thinks it's already plugged to that instance on that host? ** Also 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/1694371 Title: test_stack_snapshot_restore failing intermittently Status in heat: New Status in neutron: New Status in OpenStack Compute (nova): New Bug description: It seems like the server is going to ERROR state during rebuild. traceback: 2017-05-28 04:34:37.767757 | 2017-05-28 04:34:37.767 | Captured traceback: 2017-05-28 04:34:37.768828 | 2017-05-28 04:34:37.768 | ~~~ 2017-05-28 04:34:37.770099 | 2017-05-28 04:34:37.769 | b'Traceback (most recent call last):' 2017-05-28 04:34:37.771108 | 2017-05-28 04:34:37.770 | b' File "/opt/stack/new/heat/heat_integrationtests/functional/test_snapshot_restore.py", line 74, in test_stack_snapshot_restore' 2017-05-28 04:34:37.772364 | 2017-05-28 04:34:37.772 | b' self.stack_restore(stack_identifier, snapshot_id)' 2017-05-28 04:34:37.773407 | 2017-05-28 04:34:37.773 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 626, in stack_restore' 2017-05-28 04:34:37.774541 | 2017-05-28 04:34:37.774 | b' self._wait_for_stack_status(stack_id, wait_for_status)' 2017-05-28 04:34:37.775568 | 2017-05-28 04:34:37.775 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 357, in _wait_for_stack_status' 2017-05-28 04:34:37.776642 | 2017-05-28 04:34:37.776 | b' fail_regexp):' 2017-05-28 04:34:37.778354 | 2017-05-28 04:34:37.778 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 321, in _verify_status' 2017-05-28 04:34:37.779448 | 2017-05-28 04:34:37.779 | b' stack_status_reason=stack.stack_status_reason)' 2017-05-28 04:34:37.780644 | 2017-05-28 04:34:37.780 | b"heat_integrationtests.common.exceptions.StackBuildErrorException: Stack StackSnapshotRestoreTest-1374582671/7fb8f800-1545-4e34-a6fa-3e2adbf4443a is in RESTORE_FAILED status due to 'Error: resources.my_server: Rebuilding server failed, status 'ERROR''" 2017-05-28 04:34:37.782119 | 2017-05-28 04:34:37.781 | b'' Noticed at: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm- functional-convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/console.html#_2017-05-28_04_34_37_753094 Looks like a nova issue from the below traceback. http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm- functional-convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-n-cpu.txt.gz?level=ERROR#_May_28_04_14_49_044455 May 28 04:14:49.042877 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 6758, in _error_out_instance_on_exception May 28 04:14:49.042955 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] yield May 28 04:14:49.043027 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/co
[Yahoo-eng-team] [Bug 1694616] Re: Remove usage of parameter enforce_type
** No longer affects: glance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1694616 Title: Remove usage of parameter enforce_type Status in cloudkitty: In Progress Status in Cue: New Status in senlin: In Progress Status in watcher: New Status in zaqar: In Progress Status in Zun: In Progress Bug description: Oslo.config deprecated parameter enforce_type and change its default value to True in Ifa552de0a994e40388cbc9f7dbaa55700ca276b0. Remove the usage of it to avoid DeprecationWarning: "Using the 'enforce_type' argument is deprecated in version '4.0' and will be removed in version '5.0': The argument enforce_type has changed its default value to True and then will be removed completely." Just need the usage of enforce_type like https://review.openstack.org/#/c/463295/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloudkitty/+bug/1694616/+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 1694616] Re: Remove usage of parameter enforce_type
** Also 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/1694616 Title: Remove usage of parameter enforce_type Status in cloudkitty: In Progress Status in Cue: New Status in Glance: New Status in senlin: In Progress Status in watcher: New Status in zaqar: In Progress Status in Zun: In Progress Bug description: Oslo.config deprecated parameter enforce_type and change its default value to True in Ifa552de0a994e40388cbc9f7dbaa55700ca276b0. Remove the usage of it to avoid DeprecationWarning: "Using the 'enforce_type' argument is deprecated in version '4.0' and will be removed in version '5.0': The argument enforce_type has changed its default value to True and then will be removed completely." Just need the usage of enforce_type like https://review.openstack.org/#/c/463295/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloudkitty/+bug/1694616/+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 1694735] Re: Add configuration options for certificate validation
It's not clear what actually requires documentation from this change since we publish the config options automatically: https://docs.openstack.org/developer/nova/sample_config.html If the security guide needs to be updated, then this should be routed to the openstack-manuals project. ** Changed in: nova Status: New => Invalid -- 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/1694735 Title: Add configuration options for certificate validation Status in OpenStack Compute (nova): Invalid Bug description: https://review.openstack.org/457678 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" 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 05bf7269414789496967d10270713253c9da1d6d Author: Peter Hamilton Date: Tue Apr 18 10:18:44 2017 -0400 Add configuration options for certificate validation This change adds two configuration options to support certificate validation: (1) enable_certificate_validation, which enables the checking of certificate validity during image signature verification, and (2) default_trusted_certificate_ids, which defines a deployment-wide default list of trusted certificates that should be used for certificate validation if not overriden by the user. Both options work with the verify_glance_signatures options defined in the glance configuration group. DocImpact Change-Id: If7b6e76519b0e37115a35b180b11959fe8a24582 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1694735/+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 1618465] Re: Functional test failing because of unclosed file
Reviewed: https://review.openstack.org/362887 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=611ff130ebb0879db9f4777601f2e51340aa9f94 Submitter: Jenkins Branch:master commit 611ff130ebb0879db9f4777601f2e51340aa9f94 Author: venkatamahesh Date: Tue Aug 30 19:24:16 2016 +0530 Fixed PY35 Jenkins Gate warnings Some of the files are opened but never closed. In this patch done the changes to make the files close after the file operations are executed Change-Id: I968581d9befddbd2c8e0f7dc1ea0de7ff7bea98f Closes-Bug: #1618465 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1618465 Title: Functional test failing because of unclosed file Status in Glance: Fix Released Bug description: /home/jenkins/workspace/gate-glance-python35-db- nv/glance/tests/functional/__init__.py:647: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/tmp.b9wzMojHJU/tmpxl6ut5do/scrubber.log' mode='r' encoding='UTF-8'> http://logs.openstack.org/93/356693/5/check/gate-glance-python35-db- nv/7221e1c/console.html#_2016-08-29_23_45_56_508789 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1618465/+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 1694873] [NEW] openstack server list report "Unexpected API Error" under unbuntu liberty keystone v3
Public bug reported:
After start keystone v3 configuration on ubuntu Liberty, I run server list
command and get "unexpected API Error".
#openstack --debug server list
START with options: %s(u"['--debug', 'server', 'list']",)
options: %s(u"Namespace(access_token_endpoint='', auth_type='',
auth_url='https://192.168.0.51:5000/v3', cacert='/root/openst2.pem',
client_id='', client_secret='', cloud='', debug=True, default_domain='default',
deferred_help=False, domain_id='', domain_name='', endpoint='',
identity_provider='', identity_provider_url='', insecure=None, interface='',
log_file=None, os_compute_api_version='', os_data_processing_api_version='1.1',
os_identity_api_version='3', os_image_api_version='2',
os_network_api_version='2', os_object_api_version='', os_project_id=None,
os_project_name=None, os_queues_api_version='1.1', os_volume_api_version='',
password='***', project_domain_id='', project_domain_name='Default',
project_id='', project_name='admin', protocol='', region_name='RegionOne',
scope='', service_provider_endpoint='', timeout=600, timing=False, token='',
trust_id='', url='', user_domain_id='', user_domain_name='Default', user_id='',
username='admin', verbose_level=3, verify=None)",)
defaults: %s{'auth_type': 'password', 'compute_api_version': '2',
'database_api_version': '1.0', 'api_timeout': None, 'baremetal_api_version':
'1', 'cacert': None, 'image_api_use_tasks': False, 'floating_ip_source':
'neutron', 'key': None, 'interface': None, 'network_api_version': '2',
'image_format': 'qcow2', 'object_api_version': '1', 'image_api_version': '1',
'verify': True, 'identity_api_version': '2', 'volume_api_version': '1', 'cert':
None, 'secgroup_source': 'neutron', 'dns_api_version': '2',
'disable_vendor_agent': {}}
cloud cfg: %s(u"{'auth_type': 'password', 'compute_api_version': '2',
'database_api_version': '1.0', 'data_processing_api_version': '1.1',
'network_api_version': '2', 'image_format': 'qcow2', 'object_api_version': '1',
'queues_api_version': '1.1', 'verify': True, 'timing': False,
'dns_api_version': '2', 'verbose_level': 3, 'region_name': 'RegionOne',
'api_timeout': None, 'baremetal_api_version': '1', 'image_api_version': '2',
'auth': {'username': 'admin', 'project_name': 'admin', 'tenant_name': 'admin',
'user_domain_name': 'Default', 'auth_url': 'https://192.168.0.51:5000/v3',
'password': '***', 'project_domain_name': 'Default'}, 'default_domain':
'default', 'image_api_use_tasks': False, 'floating_ip_source': 'neutron',
'key': None, 'cacert': '/root/openst2.pem', 'deferred_help': False,
'identity_api_version': '3', 'volume_api_version': '1', 'cert': None,
'secgroup_source': 'neutron', 'timeout': 600, 'debug': True, 'interface': None,
'disable_vendor_agent': {}}",)
%(name)s API version %(version)s, cmd group %(group)s{'version': '2', 'group':
'openstack.compute.v2', 'name': 'compute'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '2', 'group':
'openstack.network.v2', 'name': 'network'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '2', 'group':
'openstack.image.v2', 'name': 'image'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '1', 'group':
'openstack.volume.v1', 'name': 'volume'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '3', 'group':
'openstack.identity.v3', 'name': 'identity'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '1', 'group':
'openstack.object_store.v1', 'name': 'object_store'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '1.1',
'group': 'openstack.data_processing.v1', 'name': 'data_processing'}
%(name)s API version %(version)s, cmd group %(group)s{'version': '1.1',
'group': 'openstack.messaging.v1', 'name': 'messaging'}
command: %s -> %s.%s('server list', 'openstackclient.compute.v2.server',
'ListServer')
Auth plugin password selected
auth_type: %s('password',)
Using auth plugin: password
Using parameters {'username': 'admin', 'project_name': 'admin', 'auth_url':
'https://192.168.0.51:5000/v3', 'tenant_name': 'admin', 'user_domain_name':
'Default', 'password': '***', 'project_domain_name': 'Default'}
Get auth_ref
REQ: curl -g -i --cacert "/root/openst2.pem" -X GET
https://192.168.0.51:5000/v3 -H "Accept: application/json" -H "User-Agent:
python-openstackclient"
Starting new HTTPS connection (1): 192.168.0.51
/usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain SSL
connections to fail. For more information, see
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
"GET /v3 HTTP/1.1" 200 253
RESP: [200] content-length: 253 vary: X-Auth-Token server: Apache connection:
close date: Thu, 01 Jun 2017 02:39:04 GMT content-type: application/json
x-openstack-request-id: req-38e6c560-fde4-4807-b51a-4111c4516f2a
RES
[Yahoo-eng-team] [Bug 1693576] Re: addFloatingIP conflict is tracing in n-api logs
Reviewed: https://review.openstack.org/468136 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=452f21183f2f80cc5673ebd3fd3e5daf039caacc Submitter: Jenkins Branch:master commit 452f21183f2f80cc5673ebd3fd3e5daf039caacc Author: Matt Riedemann Date: Thu May 25 15:00:24 2017 -0400 Handle conflict from neutron when addFloatingIP fails Neutron can raise a Conflict exception when attempting to associate a floating IP to a server when the fixed address is already associated to another floating IP. This has always resulted in a 400 response, however, it would also trace an ERROR in the nova-api logs, which is something we shouldn't be doing for an expected type of failure. This handles the Conflict in the neutronv2 API client code and re-raises an exception that the REST API controller code can handle and return as a 400 without the stacktrace in the logs. Change-Id: I27d3241300f75e2aa79a32348a3843e09123cb10 Closes-Bug: #1693576 ** Changed in: nova Status: In Progress => 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/1693576 Title: addFloatingIP conflict is tracing in n-api logs Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Status in OpenStack Compute (nova) ocata series: In Progress Bug description: This Tempest negative test was added back in March: https://github.com/openstack/tempest/commit/343ca198166ded0bbf6e23535aeae0ea15a922dc It passes but it results in an ugly stacktrace in the n-api logs: http://logs.openstack.org/89/466889/2/gate/gate-tempest-dsvm-neutron- full-ubuntu- xenial/57732b0/logs/screen-n-api.txt.gz?level=TRACE#_May_24_07_30_30_975142 Which is normally a place where we shouldn't stacktrace if it's not a 500 error. This is an expected situation, and we should be able to handle the 409 Conflict from Neutron and translate that to a proper error handled at the top REST API controller. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1693576/+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 1607714] Re: test_reassign_port_between_servers failing with tap device is busy errors in neutron xenial jobs since 7/28
Reviewed: https://review.openstack.org/349014 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a3b3e8d8314b0cedc2604be509f0f4d523a35ed5 Submitter: Jenkins Branch:master commit a3b3e8d8314b0cedc2604be509f0f4d523a35ed5 Author: Matt Riedemann Date: Thu Feb 9 15:54:41 2017 -0500 libvirt: wait for interface detach from the guest The test_reassign_port_between_servers test in Tempest creates a port in neutron and two servers. It attaches the port to the first server and then quickly detaches it and waits for the port.device_id to be unbound from the server. Then it repeats that for the second server. The interface detach from the guest is asynchronous and happens before nova unbinds the port, so there is a race where the port's device_id is unset but the interface is still on the first guest when we try to attach to the second guest, which fails. This is a latent bug, but apparently has been tickled by the move to our neutron CI jobs to use ubuntu xenial nodes. The fix is to add a detach and retry loop on the interface detach on the guest so that we can wait until the interface is gone from the guest before nova unbinds the port in neutron, which is what the Tempest test is waiting for. Then the device should be available for attaching to the second guest. This is similar to what we do with detaching volumes. Closes-Bug: #1607714 Change-Id: Ic04aad8923ea2edf1d16e32c208cd41fdf898834 ** Changed in: nova Status: In Progress => 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/1607714 Title: test_reassign_port_between_servers failing with tap device is busy errors in neutron xenial jobs since 7/28 Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Confirmed Status in OpenStack Compute (nova) ocata series: In Progress Bug description: Recent failures showing up in the tempest tests for 'test_reassign_port_between_servers'. From n-cpu.log (http://logs.openstack.org/43/298443/3/check/gate- tempest-dsvm-neutron-full-ubuntu- xenial/5acdcca/logs/screen-n-cpu.txt.gz#_2016-07-29_07_25_47_948): 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [req-572c16fd-696d-44ab-a633-49e6625b8f9c tempest-AttachInterfacesTestJSON-1497713114 tempest-AttachInterfacesTestJSON-1497713114] [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] attaching network adapter failed. 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] Traceback (most recent call last): 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 1389, in attach_interface 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] guest.attach_device(cfg, persistent=True, live=live) 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/opt/stack/new/nova/nova/virt/libvirt/guest.py", line 295, in attach_device 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] self._domain.attachDeviceFlags(device_xml, flags=flags) 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in doit 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] result = proxy_call(self._autowrap, f, *args, **kwargs) 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in proxy_call 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] rv = execute(f, *args, **kwargs) 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in execute 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] six.reraise(c, e, tb) 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in tworker 2016-07-29 07:25:47.948 20203 ERROR nova.virt.libvirt.driver [instance: 73323063-7cc3-4645-9a68-662bf80d9e42] rv = meth(*args, **kwargs) 2016-07-29 07:25:47.948 2020
[Yahoo-eng-team] [Bug 1690932] Re: SubclassSignatureTestCase isn't being used properly in libvirt volume tests
Reviewed: https://review.openstack.org/464765 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=03cb9c04f071a19fe4fd8f106cfd7e65e2045639 Submitter: Jenkins Branch:master commit 03cb9c04f071a19fe4fd8f106cfd7e65e2045639 Author: Matt Riedemann Date: Mon May 15 18:15:55 2017 -0400 libvirt: expand checks for SubclassSignatureTestCase Change I01c908add1312063f0db724110f7e5927ff281ff introduced tests to ensure that the libvirt volume drivers would have the same method signature as their parent classes, but only tested certain filesystem-style volume drivers. Because of that, change Iafb9ce4c1582715c6afac87cc9ae62e259f21b07 did not fail the tests but failed to have the correct signature for connect_volume and disconnect_volume. This change expands the tests to use the base libvirt volume driver rather than just the FS-style one so it will catch things like the new LibvirtHyperScaleVolumeDriver. Change-Id: Ibf30dbc732eb2b2755e89dece330fe9c4913dbde Closes-Bug: #1690932 ** Changed in: nova Status: In Progress => 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/1690932 Title: SubclassSignatureTestCase isn't being used properly in libvirt volume tests Status in OpenStack Compute (nova): Fix Released Bug description: SubclassSignatureTestCase isn't being used properly in the libvirt volume driver tests. It's only being used to test the drivers that extend LibvirtBaseFileSystemVolumeDriver which is not everything. It should really be used against the LibvirtBaseVolumeDriver class. For example, the new veritas hyperscale driver didn't fail the check once it was rebased to pick up this test: https://review.openstack.org/#/c/443951/14/nova/virt/libvirt/volume/vrtshyperscale.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1690932/+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 1694844] Re: Boot from volume fails when cross_az_attach=False and volume is provided to nova without an AZ for the instance
** Changed in: nova
Importance: Undecided => Medium
** Also affects: nova/ocata
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/1694844
Title:
Boot from volume fails when cross_az_attach=False and volume is
provided to nova without an AZ for the instance
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Compute (nova) ocata series:
New
Bug description:
This was recreated with a devstack change:
http://logs.openstack.org/74/467674/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-
xenial/3dbd6e9/logs/screen-n-api.txt.gz#_May_26_02_41_54_584798
In this failing test, Tempest creates a volume:
{"volume": {"status": "creating", "user_id":
"2256bb66db8741aab58a20367b00bfa2", "attachments": [], "links":
[{"href":
"https://10.39.38.35:8776/v2/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "self"}, {"href":
"https://10.39.38.35:8776/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "bookmark"}],
"availability_zone": "nova", "bootable": "false", "encrypted": false,
"created_at": "2017-05-26T02:41:45.617286", "description": null,
"updated_at": null, "volume_type": "lvmdriver-1", "name": "tempest-
TestVolumeBootPattern-volume-origin-1984626538", "replication_status":
null, "consistencygroup_id": null, "source_volid": null,
"snapshot_id": null, "multiattach": false, "metadata": {}, "id":
"55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "size": 1}}
And the AZ on the volume defaults to 'nova' because that's the default
AZ in cinder.conf.
That volume ID is then passed to create the server:
{"server": {"block_device_mapping_v2": [{"source_type": "volume",
"boot_index": 0, "destination_type": "volume", "uuid": "55a7c64a-
f7b2-4b77-8f60-c1ccda8e0c30", "delete_on_termination": true}],
"networks": [{"uuid": "da48954d-1f66-427b-892c-a7f2eb1b54a3"}],
"imageRef": "", "name": "tempest-TestVolumeBootPattern-
server-1371698056", "flavorRef": "42"}}
Which fails with the 400 InvalidVolume error because of this check in
the API:
https://github.com/openstack/nova/blob/f112dc686dadd643410575cc3487cf1632e4f689/nova/volume/cinder.py#L286
The instance is not associated with a host yet so it's not in an
aggregate, and since an AZ wasn't specified when creating an instance
(and I don't think we want people passing 'nova' as the AZ), it fails
when comparing None to 'nova'.
This is separate from bug 1497253 and change
https://review.openstack.org/#/c/366724/ because in that case Nova is
creating the volume during boot from volume and can specify the AZ for
the volume. In this bug, the volume already exists and is provided to
Nova.
We might need to be able to distinguish if the API or compute service
is calling check_availability_zone and if so, pass a default AZ in the
case of the API if one isn't defined.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694844/+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 1694844] [NEW] Boot from volume fails when cross_az_attach=False and volume is provided to nova without an AZ for the instance
Public bug reported:
This was recreated with a devstack change:
http://logs.openstack.org/74/467674/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-
xenial/3dbd6e9/logs/screen-n-api.txt.gz#_May_26_02_41_54_584798
In this failing test, Tempest creates a volume:
{"volume": {"status": "creating", "user_id":
"2256bb66db8741aab58a20367b00bfa2", "attachments": [], "links":
[{"href":
"https://10.39.38.35:8776/v2/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "self"}, {"href":
"https://10.39.38.35:8776/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "bookmark"}],
"availability_zone": "nova", "bootable": "false", "encrypted": false,
"created_at": "2017-05-26T02:41:45.617286", "description": null,
"updated_at": null, "volume_type": "lvmdriver-1", "name": "tempest-
TestVolumeBootPattern-volume-origin-1984626538", "replication_status":
null, "consistencygroup_id": null, "source_volid": null, "snapshot_id":
null, "multiattach": false, "metadata": {}, "id": "55a7c64a-
f7b2-4b77-8f60-c1ccda8e0c30", "size": 1}}
And the AZ on the volume defaults to 'nova' because that's the default
AZ in cinder.conf.
That volume ID is then passed to create the server:
{"server": {"block_device_mapping_v2": [{"source_type": "volume",
"boot_index": 0, "destination_type": "volume", "uuid": "55a7c64a-
f7b2-4b77-8f60-c1ccda8e0c30", "delete_on_termination": true}],
"networks": [{"uuid": "da48954d-1f66-427b-892c-a7f2eb1b54a3"}],
"imageRef": "", "name": "tempest-TestVolumeBootPattern-
server-1371698056", "flavorRef": "42"}}
Which fails with the 400 InvalidVolume error because of this check in
the API:
https://github.com/openstack/nova/blob/f112dc686dadd643410575cc3487cf1632e4f689/nova/volume/cinder.py#L286
The instance is not associated with a host yet so it's not in an
aggregate, and since an AZ wasn't specified when creating an instance
(and I don't think we want people passing 'nova' as the AZ), it fails
when comparing None to 'nova'.
This is separate from bug 1497253 and change
https://review.openstack.org/#/c/366724/ because in that case Nova is
creating the volume during boot from volume and can specify the AZ for
the volume. In this bug, the volume already exists and is provided to
Nova.
We might need to be able to distinguish if the API or compute service is
calling check_availability_zone and if so, pass a default AZ in the case
of the API if one isn't defined.
** Affects: nova
Importance: Undecided
Status: New
** Tags: volumes
--
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/1694844
Title:
Boot from volume fails when cross_az_attach=False and volume is
provided to nova without an AZ for the instance
Status in OpenStack Compute (nova):
New
Bug description:
This was recreated with a devstack change:
http://logs.openstack.org/74/467674/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-
xenial/3dbd6e9/logs/screen-n-api.txt.gz#_May_26_02_41_54_584798
In this failing test, Tempest creates a volume:
{"volume": {"status": "creating", "user_id":
"2256bb66db8741aab58a20367b00bfa2", "attachments": [], "links":
[{"href":
"https://10.39.38.35:8776/v2/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "self"}, {"href":
"https://10.39.38.35:8776/272882ba896341d483982dbcb1fde0f4/volumes
/55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "rel": "bookmark"}],
"availability_zone": "nova", "bootable": "false", "encrypted": false,
"created_at": "2017-05-26T02:41:45.617286", "description": null,
"updated_at": null, "volume_type": "lvmdriver-1", "name": "tempest-
TestVolumeBootPattern-volume-origin-1984626538", "replication_status":
null, "consistencygroup_id": null, "source_volid": null,
"snapshot_id": null, "multiattach": false, "metadata": {}, "id":
"55a7c64a-f7b2-4b77-8f60-c1ccda8e0c30", "size": 1}}
And the AZ on the volume defaults to 'nova' because that's the default
AZ in cinder.conf.
That volume ID is then passed to create the server:
{"server": {"block_device_mapping_v2": [{"source_type": "volume",
"boot_index": 0, "destination_type": "volume", "uuid": "55a7c64a-
f7b2-4b77-8f60-c1ccda8e0c30", "delete_on_termination": true}],
"networks": [{"uuid": "da48954d-1f66-427b-892c-a7f2eb1b54a3"}],
"imageRef": "", "name": "tempest-TestVolumeBootPattern-
server-1371698056", "flavorRef": "42"}}
Which fails with the 400 InvalidVolume error because of this check in
the API:
https://github.com/openstack/nova/blob/f112dc686dadd643410575cc3487cf1632e4f689/nova/volume/cinder.py#L286
The instance is not associated with a host yet so it's not in an
aggregate, and since an AZ wasn't specified when creating an instance
(and I don't think we want people passing 'nova' as the AZ), it fails
when comparing None to 'nova'.
This is separ
[Yahoo-eng-team] [Bug 1694834] [NEW] libvirt rollback: destroy called with wrong number of args
Public bug reported: While testing live migration, I hit an exception during libvirt.driver rollback_live_migration_at_destination. The first step is this: self.destroy(context, instance, network_info, block_device_info, destroy_disks, migrate_data) But there is no arg in the destroy method for migrate_data: def destroy(self, context, instance, network_info, block_device_info=None, destroy_disks=True): The tail end of the exception: File "/opt/stack/nova/nova/compute/manager.py", line 5896, in rollback_live_migration_at_destination destroy_disks=destroy_disks, migrate_data=migrate_data) File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 6690, in rollback_live_migration_at_destination destroy_disks, migrate_data) TypeError: destroy() takes at most 6 arguments (7 given) ubuntu/kvm/pike: commit 20f47b1a3e8e80e6f9e2373cacc2480404c3cfd9 Merge: c993572 e8afd71 Author: Jenkins Date: Wed May 31 16:34:27 2017 + Merge "Add policy description for os-networks" ** Affects: nova Importance: Undecided Status: New ** Summary changed: - libvirt rollback: destory called with wrong number of args + libvirt rollback: destroy called with wrong number of args -- 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/1694834 Title: libvirt rollback: destroy called with wrong number of args Status in OpenStack Compute (nova): New Bug description: While testing live migration, I hit an exception during libvirt.driver rollback_live_migration_at_destination. The first step is this: self.destroy(context, instance, network_info, block_device_info, destroy_disks, migrate_data) But there is no arg in the destroy method for migrate_data: def destroy(self, context, instance, network_info, block_device_info=None, destroy_disks=True): The tail end of the exception: File "/opt/stack/nova/nova/compute/manager.py", line 5896, in rollback_live_migration_at_destination destroy_disks=destroy_disks, migrate_data=migrate_data) File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 6690, in rollback_live_migration_at_destination destroy_disks, migrate_data) TypeError: destroy() takes at most 6 arguments (7 given) ubuntu/kvm/pike: commit 20f47b1a3e8e80e6f9e2373cacc2480404c3cfd9 Merge: c993572 e8afd71 Author: Jenkins Date: Wed May 31 16:34:27 2017 + Merge "Add policy description for os-networks" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1694834/+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 1694537] Re: Instance creation fails with SSL, keystone v3
The root cause for this is HAProxy timing out and terminating the TCP
session. The hint in the error was the EOF:
SSLError: SSL exception connecting to
https://keystone-.net:5000/v3/auth/tokens: ("bad handshake:
SysCallError(-1, 'Unexpected EOF')",)
Bumping up the
haproxy-*-timeout values for the API charms resolved the issue for CLI driven
instance create commands.
There is still some question if instance creation via horizon has a remaining
bug or timeout.
I am marking the nova-compute and nova-cloud-controller projects as invalid for
this bug. If a horizon bug still remains we can add the openstack-dashboard
project to this bug.
** Changed in: nova
Status: Incomplete => Invalid
** Changed in: charm-nova-cloud-controller
Status: Incomplete => Invalid
--
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/1694537
Title:
Instance creation fails with SSL, keystone v3
Status in OpenStack nova-cloud-controller charm:
Invalid
Status in OpenStack Compute (nova):
Invalid
Bug description:
OS version is Ocata, with SSL enabled across the entire cloud.
Using the Keystone-LDAP charm to allow AD user authentication to the
OS deployment. AD admin users can login, and have limited admin
access.
If an AD user is added to a project on either the AD domain or the
admin_default domain as an admin, they are able to request an instance
but the instance creation errors out with:
http://paste.ubuntu.com/24727101/
There is an associated error in nova-cloud-controller's apache2 nova-
placement error log: http://paste.ubuntu.com/24727106/
Creating an instance with a local administrator on the admin_domain
domain on a project in the admin domain works without issue. However
it does not work while logged in as a local administrator (who has
admin rights added) on a project created in the AD domain.
The root of the issue seems to be communication between the nova
scheduler and the nova placement api, specifically where if a token
originates from the AD domain it has insufficient privileges to
perform administrative action between services.
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1694537/+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 1694614] Re: Docs job on jenkins failing
Still failing on pyroute2 (but how has it passed the gate for the first patch?..) ** Changed in: neutron Status: Fix Released => 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/1694614 Title: Docs job on jenkins failing Status in neutron: Confirmed Bug description: I see failed gate-neutron-docs-ubuntu-xenial in many jobs since yesterday. It always fails with error like e.g. in http://logs.openstack.org/60/469260/2/check/gate-neutron-docs-ubuntu- xenial/e55b579/console.html#_2017-05-30_22_18_04_277430 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694614/+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 1694801] [NEW] sysconfig needs fix for ipv6 gateway routes
Public bug reported: Static IPV6 subnet with a ipv6 route fails to set the default IPV6 gateway. With cloud-init master: % cat ipv6-static.yaml network: version: 1 config: - type: physical name: interface0 mac_address: "52:54:00:12:34:00" subnets: - type: static address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3 netmask: ':::::' routes: - gateway: 2001:4800:78ff:1b::1 netmask: '::' network: '::' % ./tools/net-convert.py --network-data ipv6-static.yaml \ --kind yaml --output-kind sysconfig -d target-sysconfig % grep -nr IPV6_DEFAULTGW target-sysconfig/; echo $? 1 Currently only the subnet is checked for 'ipv6' setting, however, the routes array may include a mix of v4 or v6 configurations, in particular, the gateway in a route may be ipv6, and if so, should export the value via IPV6_DEFAULTGW in the ifcfg- file. Additionally, if the route is v6, it should rendering a routes6- file; this is present but missing the 'dev ' scoping. % cat target-sysconfig/etc/sysconfig/network-scripts/route6-interface0 # Created by cloud-init on instance boot automatically, do not edit. # ::/0 via 2001:4800:78ff:1b::1 ** Affects: cloud-init Importance: Undecided Status: New ** Tags: centos7 -- 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/1694801 Title: sysconfig needs fix for ipv6 gateway routes Status in cloud-init: New Bug description: Static IPV6 subnet with a ipv6 route fails to set the default IPV6 gateway. With cloud-init master: % cat ipv6-static.yaml network: version: 1 config: - type: physical name: interface0 mac_address: "52:54:00:12:34:00" subnets: - type: static address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3 netmask: ':::::' routes: - gateway: 2001:4800:78ff:1b::1 netmask: '::' network: '::' % ./tools/net-convert.py --network-data ipv6-static.yaml \ --kind yaml --output-kind sysconfig -d target-sysconfig % grep -nr IPV6_DEFAULTGW target-sysconfig/; echo $? 1 Currently only the subnet is checked for 'ipv6' setting, however, the routes array may include a mix of v4 or v6 configurations, in particular, the gateway in a route may be ipv6, and if so, should export the value via IPV6_DEFAULTGW in the ifcfg- file. Additionally, if the route is v6, it should rendering a routes6- file; this is present but missing the 'dev ' scoping. % cat target-sysconfig/etc/sysconfig/network-scripts/route6-interface0 # Created by cloud-init on instance boot automatically, do not edit. # ::/0 via 2001:4800:78ff:1b::1 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1694801/+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 1694190] Re: qos scenario tests failure for linuxbridge
Reviewed: https://review.openstack.org/468793
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=9fbd9eb3b7b01b5503997655ae5e8729442801eb
Submitter: Jenkins
Branch:master
commit 9fbd9eb3b7b01b5503997655ae5e8729442801eb
Author: Rodolfo Alonso Hernandez
Date: Mon May 29 08:54:35 2017 +0100
Change supported vif type in Linux Bridge.
With [1], the vif_type for a Linux Bridge port is set
to 'tap', replacing 'bridge'. This definition needs to be
changed in the list of supported vif types in the pluging
driver.
[1] https://review.openstack.org/#/c/447150/
Change-Id: I715565627b2446533298b5905edbaa256bd84c92
Closes-Bug: #1694190
** 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/1694190
Title:
qos scenario tests failure for linuxbridge
Status in neutron:
Fix Released
Bug description:
it should skip if the functionality is not supported.
it has require_qos_rule_type check but it's broken after
Ia00d349625db358ab486802fc0ff2e69eaa3895e .
eg. http://logs.openstack.org/26/468326/1/check/gate-tempest-dsvm-
neutron-scenario-linuxbridge-ubuntu-xenial-
nv/54e3dbe/testr_results.html.gz
NOTE: the CI has both of ovs and linuxbridge MDs enabled.
Traceback (most recent call last):
File "/opt/stack/new/neutron/neutron/tests/tempest/scenario/test_qos.py",
line 168, in test_qos
qos_policy_id=policy_id)
File
"/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py",
line 154, in _update
resp, body = self.put(uri, post_data)
File "tempest/lib/common/rest_client.py", line 334, in put
return self.request('PUT', url, extra_headers, headers, body, chunked)
File "tempest/lib/common/rest_client.py", line 659, in request
self._error_checker(resp, resp_body)
File "tempest/lib/common/rest_client.py", line 780, in _error_checker
raise exceptions.Conflict(resp_body, resp=resp)
tempest.lib.exceptions.Conflict: An object with that identifier already exists
Details: {u'message': u'Rule bandwidth_limit is not supported by port
6f42de3d-43ad-4d27-a523-efc0f60c0944', u'detail': u'', u'type':
u'QosRuleNotSupported'}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694190/+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 1694769] Re: Nova fails to plug port because of missing ipset when calling iptables-restore
Backports here:
https://review.openstack.org/#/q/I19d62a8ac730aba2586b9f8eb08e153746ec2bcb,n,z
** Also affects: os-vif
Importance: Undecided
Status: New
** Changed in: os-vif
Status: New => Confirmed
** Changed in: neutron
Status: Confirmed => Won't Fix
** Changed in: nova
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/1694769
Title:
Nova fails to plug port because of missing ipset when calling
iptables-restore
Status in neutron:
Won't Fix
Status in OpenStack Compute (nova):
Invalid
Status in os-vif:
Confirmed
Bug description:
This is Ocata, linuxbridge.
http://logs.openstack.org/95/466395/3/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-xenial/e5923b4/logs/testr_results.html.gz
File "tempest/common/compute.py", line 188, in create_test_server
clients.servers_client, server['id'], wait_until)
File "tempest/common/waiters.py", line 76, in wait_for_server_status
server_id=server_id)
tempest.exceptions.BuildErrorException: Server
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d failed to build and is in ERROR status
Details: {u'created': u'2017-05-27T03:00:23Z', u'code': 500, u'message': u'No
valid host was found. There are not enough hosts available.'}
The failure in nova-cpu log:
http://logs.openstack.org/95/466395/3/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-
xenial/e5923b4/logs/screen-n-cpu.txt.gz#_2017-05-27_03_00_21_716
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager
[req-06c29149-80d9-4923-b9c4-54591a3f5e7e
tempest-ServerActionsTestJSON-1792219232
tempest-ServerActionsTestJSON-1792219232] [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] Instance failed to spawn
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] Traceback (most recent call last):
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2124, in _build_resources
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] yield resources
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/compute/manager.py", line 1930, in
_build_and_run_instance
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] block_device_info=block_device_info)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 2698, in spawn
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] destroy_disks_on_failure=True)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5114, in
_create_domain_and_network
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] destroy_disks_on_failure)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.force_reraise()
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] six.reraise(self.type_, self.value,
self.tb)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5077, in
_create_domain_and_network
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.plug_vifs(instance, network_info)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 749, in plug_vifs
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.vif_driver.plug(instance, vif)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/vif.py", line 786, in plug
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8
[Yahoo-eng-team] [Bug 1694782] [NEW] Invalid params is passed to novaAPI.getFlavors call
Public bug reported:
Hi,
In
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/static/dashboard/project/workflow
/launch-instance/launch-instance-model.service.js#L253
where novaAPI.getFlavors() is called with params that does not match the
Nova API in
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core
/openstack-service-api/nova.service.js#L471
where a params object is expected.
My understanding is that the Nova API is expecting params object of form below
from launch-instance-model call
{
'params' : {
'is_public' = 'true',
'get_extras' = 'true',
}
}
** 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/1694782
Title:
Invalid params is passed to novaAPI.getFlavors call
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Hi,
In
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/static/dashboard/project/workflow
/launch-instance/launch-instance-model.service.js#L253
where novaAPI.getFlavors() is called with params that does not match
the Nova API in
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core
/openstack-service-api/nova.service.js#L471
where a params object is expected.
My understanding is that the Nova API is expecting params object of form
below from launch-instance-model call
{
'params' : {
'is_public' = 'true',
'get_extras' = 'true',
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1694782/+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 1694772] [NEW] test_keepalived_multiple_sighups_does_not_forfeit_mastership fails because of "AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN'"
Public bug reported: http://logs.openstack.org/82/465182/1/check/gate-neutron-dsvm-fullstack- ubuntu-xenial/a0a5ab4/logs/dsvm-fullstack- logs/TestHAL3Agent.test_keepalived_multiple_sighups_does_not_forfeit_mastership/neutron-l3-agent --2017-05-31--17-35-57-322793.txt.gz?level=TRACE 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [req-2ccd326a-186e-4c00-85cc-17ed633b93dc - - - - -] 'module' object has no attribute 'LINUX_DEV_LEN' 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info Traceback (most recent call last): 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/common/utils.py", line 287, in call 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info return func(*args, **kwargs) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 1094, in process 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self.process_external(agent) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 869, in process_external 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self._process_external_gateway(ex_gw_port, agent.pd) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 750, in _process_external_gateway 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info interface_name = self.get_external_device_name(ex_gw_port_id) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/tests/common/agents/l3_agent.py", line 96, in get_external_device_name 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [:iptables_firewall.LINUX_DEV_LEN]) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN' This is probably Newton only. ** Affects: neutron Importance: High Assignee: Ihar Hrachyshka (ihar-hrachyshka) Status: In Progress ** Tags: fullstack gate-failure l3-ha ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Status: New => In Progress ** Changed in: neutron Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka) ** Tags added: fullstack gate-failure l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1694772 Title: test_keepalived_multiple_sighups_does_not_forfeit_mastership fails because of "AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN'" Status in neutron: In Progress Bug description: http://logs.openstack.org/82/465182/1/check/gate-neutron-dsvm- fullstack-ubuntu-xenial/a0a5ab4/logs/dsvm-fullstack- logs/TestHAL3Agent.test_keepalived_multiple_sighups_does_not_forfeit_mastership/neutron-l3-agent --2017-05-31--17-35-57-322793.txt.gz?level=TRACE 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [req-2ccd326a-186e-4c00-85cc-17ed633b93dc - - - - -] 'module' object has no attribute 'LINUX_DEV_LEN' 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info Traceback (most recent call last): 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/common/utils.py", line 287, in call 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info return func(*args, **kwargs) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 1094, in process 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self.process_external(agent) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 869, in process_external 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self._process_external_gateway(ex_gw_port, agent.pd) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 750, in _process_external_gateway 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info interface_name = self.get_external_device_name(ex_gw_port_id) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/tests/common/agents/l3_agent.py", line 96, in get_external_device_name 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [:iptables_firewall.LINUX_DEV_LEN]) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN' This is probably Newton only. To manage notifications about this bu
[Yahoo-eng-team] [Bug 1694769] [NEW] Nova fails to plug port because of missing ipset when calling iptables-restore
Public bug reported:
This is Ocata, linuxbridge.
http://logs.openstack.org/95/466395/3/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-xenial/e5923b4/logs/testr_results.html.gz
File "tempest/common/compute.py", line 188, in create_test_server
clients.servers_client, server['id'], wait_until)
File "tempest/common/waiters.py", line 76, in wait_for_server_status
server_id=server_id)
tempest.exceptions.BuildErrorException: Server
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d failed to build and is in ERROR status
Details: {u'created': u'2017-05-27T03:00:23Z', u'code': 500, u'message': u'No
valid host was found. There are not enough hosts available.'}
The failure in nova-cpu log: http://logs.openstack.org/95/466395/3/gate
/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-
xenial/e5923b4/logs/screen-n-cpu.txt.gz#_2017-05-27_03_00_21_716
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager
[req-06c29149-80d9-4923-b9c4-54591a3f5e7e
tempest-ServerActionsTestJSON-1792219232
tempest-ServerActionsTestJSON-1792219232] [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] Instance failed to spawn
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] Traceback (most recent call last):
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2124, in _build_resources
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] yield resources
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/compute/manager.py", line 1930, in
_build_and_run_instance
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] block_device_info=block_device_info)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 2698, in spawn
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] destroy_disks_on_failure=True)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5114, in
_create_domain_and_network
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] destroy_disks_on_failure)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.force_reraise()
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] six.reraise(self.type_, self.value,
self.tb)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5077, in
_create_domain_and_network
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.plug_vifs(instance, network_info)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 749, in plug_vifs
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self.vif_driver.plug(instance, vif)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/vif.py", line 786, in plug
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] self._plug_os_vif(instance, vif_obj)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] File
"/opt/stack/new/nova/nova/virt/libvirt/vif.py", line 766, in _plug_os_vif
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] raise exception.InternalError(msg)
2017-05-27 03:00:21.716 1385 ERROR nova.compute.manager [instance:
2a04ac11-2ec6-4a0d-a8f5-c89d129e881d] InternalError: Failure running os_vif
plugin plug method: Failed to plug VIF
VIFBridge(active=False,address=fa:16:3e:16:2c:4d,bridge_name='brq9c933655-e1',has_traffic_filtering=True,id=416d65ee-709e-4b50-a0f1-23d988773b9f,network=Network(9c933655-e176-41b2-9b
[Yahoo-eng-team] [Bug 1694764] [NEW] test_metadata_proxy_respawned failed to spawn metadata proxy
Public bug reported:
This is on Newton.
http://logs.openstack.org/82/465182/1/gate/gate-neutron-dsvm-functional-
ubuntu-xenial/2eae399/testr_results.html.gz
Traceback (most recent call last):
File "neutron/tests/functional/agent/test_dhcp_agent.py", line 322, in
test_metadata_proxy_respawned
exception=RuntimeError("Metadata proxy didn't respawn"))
File "neutron/common/utils.py", line 821, in wait_until_true
eventlet.sleep(sleep)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py",
line 34, in sleep
hub.switch()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py",
line 294, in switch
return self.greenlet.switch()
RuntimeError: Metadata proxy didn't respawn
The proxy process is started here:
http://logs.openstack.org/82/465182/1/gate/gate-neutron-dsvm-functional-
ubuntu-xenial/2eae399/logs/dsvm-functional-
logs/neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_metadata_proxy_respawned.txt.gz#_2017-05-27_16_55_06_897
Then later (not sure if related) we see this:
2017-05-27 16:55:12.768 11565 DEBUG neutron.agent.linux.external_process
[req-4c03cff5-0c93-422e-a542-423c54d67807 - - - - -] Process for
bcaf27b6-7bdc-4569-93f0-1a4d51e21040 pid 27762 is stale, ignoring signal
9 disable neutron/agent/linux/external_process.py:121
Nothing interesting can be found in syslog.
** Affects: neutron
Importance: High
Status: Confirmed
** Tags: functional-tests gate-failure l3-ipam-dhcp
** Changed in: neutron
Importance: Undecided => High
** Changed in: neutron
Status: New => Confirmed
** Tags added: functional-tests gate-failure
** Tags added: l3-ipam-dhcp
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1694764
Title:
test_metadata_proxy_respawned failed to spawn metadata proxy
Status in neutron:
Confirmed
Bug description:
This is on Newton.
http://logs.openstack.org/82/465182/1/gate/gate-neutron-dsvm-
functional-ubuntu-xenial/2eae399/testr_results.html.gz
Traceback (most recent call last):
File "neutron/tests/functional/agent/test_dhcp_agent.py", line 322, in
test_metadata_proxy_respawned
exception=RuntimeError("Metadata proxy didn't respawn"))
File "neutron/common/utils.py", line 821, in wait_until_true
eventlet.sleep(sleep)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py",
line 34, in sleep
hub.switch()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py",
line 294, in switch
return self.greenlet.switch()
RuntimeError: Metadata proxy didn't respawn
The proxy process is started here:
http://logs.openstack.org/82/465182/1/gate/gate-neutron-dsvm-
functional-ubuntu-xenial/2eae399/logs/dsvm-functional-
logs/neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_metadata_proxy_respawned.txt.gz#_2017-05-27_16_55_06_897
Then later (not sure if related) we see this:
2017-05-27 16:55:12.768 11565 DEBUG
neutron.agent.linux.external_process [req-
4c03cff5-0c93-422e-a542-423c54d67807 - - - - -] Process for
bcaf27b6-7bdc-4569-93f0-1a4d51e21040 pid 27762 is stale, ignoring
signal 9 disable neutron/agent/linux/external_process.py:121
Nothing interesting can be found in syslog.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694764/+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 1646107] Re: Functional job times out on xenial
I think this is not happening anymore. I will close the bug. ** Changed in: neutron Status: Confirmed => 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/1646107 Title: Functional job times out on xenial Status in neutron: Fix Released Bug description: logstash-querry: http://logstash.openstack.org/#dashboard/file/logstash.json?query=build_name%3A%5C %22gate-neutron-dsvm-functional-ubuntu- xenial%5C%22%20AND%20build_status%3A%5C%22FAILURE%5C%22%20AND%20tags%3A%5C%22console%5C%22%20AND%20message%3A%5C%22Killed%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20timeout%20-s%209%20%5C%22 9 hits in 2 days To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1646107/+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 1691805] Re: functional pecan tests fail with old Routes (< 2.3.0)
** 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/1691805
Title:
functional pecan tests fail with old Routes (< 2.3.0)
Status in neutron:
Fix Released
Bug description:
Several neutron functional tests are failing when Routes is <2.3.0.
Specifically the pecan_wsgi.test_controllers.
Tests:
neutron.tests.functional.pecan_wsgi.test_controllers.TestRouterController.test_methods
neutron.tests.functional.pecan_wsgi.test_controllers.TestV2Controller.test_get_no_trailing_slash
neutron.tests.functional.pecan_wsgi.test_controllers.TestResourceController.test_methods
Failure:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/oslo_middleware/catch_errors.py",
line 40, in __call__
response = req.get_response(self.application)
File "/usr/lib/python2.7/site-packages/webob/request.py", line 1316, in send
application, catch_exc_info=False)
File "/usr/lib/python2.7/site-packages/webob/request.py", line 1280, in
call_application
app_iter = application(self.environ, start_response)
File "/usr/lib/python2.7/site-packages/webob/dec.py", line 145, in __call__
return resp(environ, start_response)
File "/usr/lib/python2.7/site-packages/routes/middleware.py", line 80, in
__call__
config.environ = environ
File "/usr/lib/python2.7/site-packages/routes/__init__.py", line 22, in
__setattr__
self.load_wsgi_environ(value)
File "/usr/lib/python2.7/site-packages/routes/__init__.py", line 51, in
load_wsgi_environ
result = mapper.routematch(path)
File "/usr/lib/python2.7/site-packages/routes/mapper.py", line 688, in
routematch
raise RoutesException('URL or environ must be provided')
RoutesException: URL or environ must be provided
}}}
Traceback (most recent call last):
File "neutron/tests/base.py", line 115, in func
return f(self, *args, **kwargs)
File "neutron/tests/functional/pecan_wsgi/test_controllers.py", line 110,
in test_get_no_trailing_slash
self.assertEqual(response.status_int, 404)
File "/usr/lib/python2.7/site-packages/testtools/testcase.py", line 350, in
assertEqual
self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/site-packages/testtools/testcase.py", line 435, in
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 500 != 404
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1691805/+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 1694614] Re: Docs job on jenkins failing
Reviewed: https://review.openstack.org/469517 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6cfe39708fd8a25d06335780d8bcc6afb4224443 Submitter: Jenkins Branch:master commit 6cfe39708fd8a25d06335780d8bcc6afb4224443 Author: Ihar Hrachyshka Date: Wed May 31 07:39:11 2017 -0700 Fixed docs job failure Removed one orphan reference of unclear value (pudb), and moved another one into the text itself. This allows to pass gate with new sphinx. Change-Id: I943d9b0904731ebcc4d3fd3a9b686fd08b03c48b Closes-Bug: #1694614 ** 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/1694614 Title: Docs job on jenkins failing Status in neutron: Fix Released Bug description: I see failed gate-neutron-docs-ubuntu-xenial in many jobs since yesterday. It always fails with error like e.g. in http://logs.openstack.org/60/469260/2/check/gate-neutron-docs-ubuntu- xenial/e55b579/console.html#_2017-05-30_22_18_04_277430 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694614/+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 1694753] [NEW] QosPolicyDbObjectTestCase.test_update_objects failed because it couldn't find a matching object
Public bug reported: 2017-05-31 15:22:20.901842 | FAIL: neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_update_objects 2017-05-31 15:22:20.901856 | tags: worker-4 2017-05-31 15:22:20.901894 | -- 2017-05-31 15:22:20.901912 | Traceback (most recent call last): 2017-05-31 15:22:20.901946 | File "neutron/tests/base.py", line 115, in func 2017-05-31 15:22:20.901964 | return f(self, *args, **kwargs) 2017-05-31 15:22:20.901992 | File "neutron/tests/unit/objects/test_base.py", line 1747, in test_update_objects 2017-05-31 15:22:20.902013 | self.assertEqual(1, len(new_objs)) 2017-05-31 15:22:20.902066 | File "/home/jenkins/workspace/neutron-coverage-ubuntu-xenial/.tox/cover/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2017-05-31 15:22:20.902093 | self.assertThat(observed, matcher, message) 2017-05-31 15:22:20.902139 | File "/home/jenkins/workspace/neutron-coverage-ubuntu-xenial/.tox/cover/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2017-05-31 15:22:20.902155 | raise mismatch_error 2017-05-31 15:22:20.902175 | testtools.matchers._impl.MismatchError: 1 != 0 http://logs.openstack.org/31/469231/2/check/neutron-coverage-ubuntu- xenial/98cd310/console.html Of all filters used to match the object that could change in flight is revision_number. Others cannot change between updates and fetches. ** 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/1694753 Title: QosPolicyDbObjectTestCase.test_update_objects failed because it couldn't find a matching object Status in neutron: New Bug description: 2017-05-31 15:22:20.901842 | FAIL: neutron.tests.unit.objects.qos.test_policy.QosPolicyDbObjectTestCase.test_update_objects 2017-05-31 15:22:20.901856 | tags: worker-4 2017-05-31 15:22:20.901894 | -- 2017-05-31 15:22:20.901912 | Traceback (most recent call last): 2017-05-31 15:22:20.901946 | File "neutron/tests/base.py", line 115, in func 2017-05-31 15:22:20.901964 | return f(self, *args, **kwargs) 2017-05-31 15:22:20.901992 | File "neutron/tests/unit/objects/test_base.py", line 1747, in test_update_objects 2017-05-31 15:22:20.902013 | self.assertEqual(1, len(new_objs)) 2017-05-31 15:22:20.902066 | File "/home/jenkins/workspace/neutron-coverage-ubuntu-xenial/.tox/cover/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2017-05-31 15:22:20.902093 | self.assertThat(observed, matcher, message) 2017-05-31 15:22:20.902139 | File "/home/jenkins/workspace/neutron-coverage-ubuntu-xenial/.tox/cover/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2017-05-31 15:22:20.902155 | raise mismatch_error 2017-05-31 15:22:20.902175 | testtools.matchers._impl.MismatchError: 1 != 0 http://logs.openstack.org/31/469231/2/check/neutron-coverage-ubuntu- xenial/98cd310/console.html Of all filters used to match the object that could change in flight is revision_number. Others cannot change between updates and fetches. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694753/+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 1694524] Re: Neutron OVS agent fails to start when neutron-server is not available
** Also affects: tripleo Importance: Undecided Status: New ** Changed in: tripleo Status: New => Triaged ** Changed in: tripleo Milestone: None => pike-2 ** Changed in: tripleo Importance: Undecided => Critical ** Tags added: alert ci promotion-blocker -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1694524 Title: Neutron OVS agent fails to start when neutron-server is not available Status in neutron: Confirmed Status in tripleo: Triaged Bug description: 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp [req-34115ed3-3043-4fcb-ba3f-ab0e4eb0e83c - - - - -] Agent main thread died of an exception 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp Traceback (most recent call last): 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_ryuapp.py", line 40, in agent_main_wrapper 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp ovs_agent.main(bridge_classes) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 2166, in main 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp agent = OVSNeutronAgent(bridge_classes, cfg.CONF) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 180, in __init__ 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.setup_rpc() 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/osprofiler/profiler.py", line 153, in wrapper 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp return f(*args, **kwargs) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py", line 362, in setup_rpc 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.plugin_rpc = OVSPluginApi(topics.PLUGIN) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/agent/rpc.py", line 182, in __init__ 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp self.remote_resource_cache = create_cache_for_l2_agent() 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/agent/rpc.py", line 174, in create_cache_for_l2_agent 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp rcache.bulk_flood_cache() 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/agent/resource_cache.py", line 55, in bulk_flood_cache 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp for resource in puller.bulk_pull(context, rtype): 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/oslo_log/helpers.py", line 48, in wrapper 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp return method(*args, **kwargs) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/api/rpc/handlers/resources_rpc.py", line 109, in bulk_pull 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp version=resource_type_cls.VERSION, filter_kwargs=filter_kwargs) 2017-05-30 18:58:01.947 27929 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp File "/usr/lib/python2.7/site-packages/neutron/common/rpc.py", line 174, in call 2017-05-30 18:58:01.94
[Yahoo-eng-team] [Bug 1645918] Re: Investigate what's involved in remove the <2.0.0 cap for psutil in g-r
psutil was uncapped and updated ** Changed in: openstack-requirements Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1645918 Title: Investigate what's involved in remove the <2.0.0 cap for psutil in g-r Status in Glance: New Status in OpenStack Global Requirements: Fix Released Bug description: Various projects and distributions would like to move to a newer versions of psutils. psutils was capped in 2014 when 2.0 came out because back then most projects were not compatible with it. psutil 2.x and above has a lot of API changes as described in: https://github.com/giampaolo/psutil/blob/master/HISTORY.rst In many cases the adjustments are straightforward and can be made in a compatible fashion, allowing us to remove the cap and eventually move to a higher minimum version. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1645918/+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 1694735] [NEW] Add configuration options for certificate validation
Public bug reported: https://review.openstack.org/457678 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" 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 05bf7269414789496967d10270713253c9da1d6d Author: Peter Hamilton Date: Tue Apr 18 10:18:44 2017 -0400 Add configuration options for certificate validation This change adds two configuration options to support certificate validation: (1) enable_certificate_validation, which enables the checking of certificate validity during image signature verification, and (2) default_trusted_certificate_ids, which defines a deployment-wide default list of trusted certificates that should be used for certificate validation if not overriden by the user. Both options work with the verify_glance_signatures options defined in the glance configuration group. DocImpact Change-Id: If7b6e76519b0e37115a35b180b11959fe8a24582 ** Affects: nova Importance: Undecided Status: New ** Tags: doc nova -- 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/1694735 Title: Add configuration options for certificate validation Status in OpenStack Compute (nova): New Bug description: https://review.openstack.org/457678 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" 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 05bf7269414789496967d10270713253c9da1d6d Author: Peter Hamilton Date: Tue Apr 18 10:18:44 2017 -0400 Add configuration options for certificate validation This change adds two configuration options to support certificate validation: (1) enable_certificate_validation, which enables the checking of certificate validity during image signature verification, and (2) default_trusted_certificate_ids, which defines a deployment-wide default list of trusted certificates that should be used for certificate validation if not overriden by the user. Both options work with the verify_glance_signatures options defined in the glance configuration group. DocImpact Change-Id: If7b6e76519b0e37115a35b180b11959fe8a24582 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1694735/+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 1694736] [NEW] tempest.api.compute.servers.test_device_tagging fails with libvirt-xen
Public bug reported:
On the Xen Project CI, two new tests always fails:
tempest.api.compute.servers.test_device_tagging.DeviceTaggingTest.test_device_tagging
tempest.api.compute.servers.test_device_tagging.DeviceTaggingTestV2_42.test_device_tagging
It appear that the test is trying to ssh to the instance while the
instance itself is powering off.
from tempest, Captured pythonlogging:
2017-05-31 07:41:22,451 28296 INFO
[tempest.api.compute.servers.test_device_tagging] Attempting to verify tagged
devices in server d7004fb9-c241-4976-befb-85af3771778f via the metadata
service: http://169.254.169.254/openstack/latest/meta_data.json
2017-05-31 07:41:22,452 28296 DEBUG
[tempest.lib.common.utils.linux.remote_client] Remote command: set -eu -o
pipefail; PATH=$PATH:/sbin; curl -V
2017-05-31 07:41:22,453 28296 INFO [tempest.lib.common.ssh] Creating
ssh connection to '172.24.5.4:22' as 'cirros' with public key authentication
2017-05-31 07:41:25,451 28296 WARNING [tempest.lib.common.ssh] Failed to
establish authenticated ssh connection to cirros@172.24.5.4 ([Errno None]
Unable to connect to port 22 on 172.24.5.4). Number attempts: 1. Retry after 2
seconds.
>From screen-n-cpu.txt.gz:
May 31 07:41:30.385202 ds-xen-rax-iad-10748 nova-compute[21012]: DEBUG
nova.virt.driver [-] Emitting event Stopped> {{(pid=21012) emit_event
/opt/stack/new/nova/nova/virt/driver.py:1446}}
May 31 07:41:30.385567 ds-xen-rax-iad-10748 nova-compute[21012]: INFO
nova.compute.manager [-] [instance: d7004fb9-c241-4976-befb-85af3771778f] VM
Stopped (Lifecycle Event)
More logs can be found at:
http://logs.openstack.xenproject.org/80/394480/35/check/dsvm-tempest-xen/ef343be/
** Affects: nova
Importance: Undecided
Status: New
** Tags: xen
--
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/1694736
Title:
tempest.api.compute.servers.test_device_tagging fails with libvirt-xen
Status in OpenStack Compute (nova):
New
Bug description:
On the Xen Project CI, two new tests always fails:
tempest.api.compute.servers.test_device_tagging.DeviceTaggingTest.test_device_tagging
tempest.api.compute.servers.test_device_tagging.DeviceTaggingTestV2_42.test_device_tagging
It appear that the test is trying to ssh to the instance while the
instance itself is powering off.
from tempest, Captured pythonlogging:
2017-05-31 07:41:22,451 28296 INFO
[tempest.api.compute.servers.test_device_tagging] Attempting to verify tagged
devices in server d7004fb9-c241-4976-befb-85af3771778f via the metadata
service: http://169.254.169.254/openstack/latest/meta_data.json
2017-05-31 07:41:22,452 28296 DEBUG
[tempest.lib.common.utils.linux.remote_client] Remote command: set -eu -o
pipefail; PATH=$PATH:/sbin; curl -V
2017-05-31 07:41:22,453 28296 INFO [tempest.lib.common.ssh] Creating
ssh connection to '172.24.5.4:22' as 'cirros' with public key authentication
2017-05-31 07:41:25,451 28296 WARNING [tempest.lib.common.ssh] Failed to
establish authenticated ssh connection to cirros@172.24.5.4 ([Errno None]
Unable to connect to port 22 on 172.24.5.4). Number attempts: 1. Retry after 2
seconds.
From screen-n-cpu.txt.gz:
May 31 07:41:30.385202 ds-xen-rax-iad-10748 nova-compute[21012]: DEBUG
nova.virt.driver [-] Emitting event Stopped> {{(pid=21012) emit_event
/opt/stack/new/nova/nova/virt/driver.py:1446}}
May 31 07:41:30.385567 ds-xen-rax-iad-10748 nova-compute[21012]: INFO
nova.compute.manager [-] [instance: d7004fb9-c241-4976-befb-85af3771778f] VM
Stopped (Lifecycle Event)
More logs can be found at:
http://logs.openstack.xenproject.org/80/394480/35/check/dsvm-tempest-xen/ef343be/
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694736/+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 1693600] Re: Boot from volume fails when cross_az_attach=False due to: ObjectActionError: Object action obj_load_attr failed because: attribute host not lazy-loadable
Reviewed: https://review.openstack.org/468147
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=91bd79058abf79978335010a325952f17729d7a5
Submitter: Jenkins
Branch:master
commit 91bd79058abf79978335010a325952f17729d7a5
Author: Matt Riedemann
Date: Thu May 25 15:46:22 2017 -0400
Avoid lazy-load error when getting instance AZ
When [cinder]cross_az_attach=False (not the default) and doing
boot from volume, the API code validates the BDM by seeing if
the instance and the volume are in the same availability zone.
To get the AZ for the instance, the code is first trying to get
the instance.host value.
In Ocata we stopped creating the instance in the API and moved that
to conductor for cells v2. So the Instance object in this case now
is created in the _provision_instances method and stored in the
BuildRequest object. Since there is no host to set on the instance
yet and the Instance object wasn't populated from DB values, which
before would set the host field on the instance object to None by
default, trying to get instance.host will lazy-load the field and
it blows up with ObjectActionError.
The correct thing to do here is check if the host attribute is set
on the Instance object. There is clear intent to assume host is
not set in the instance since it was using instance.get('host'),
probably from way back in the days when the instance in this case
was a dict. So it's expecting to handle None, but we need to
modernize how that is checked.
Change-Id: I0dccb6a416dfe0eae4f7c52dfc28786a449b17bd
Closes-Bug: #1693600
** Changed in: nova
Status: In Progress => 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/1693600
Title:
Boot from volume fails when cross_az_attach=False due to:
ObjectActionError: Object action obj_load_attr failed because:
attribute host not lazy-loadable
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) ocata series:
Triaged
Bug description:
Reproduced here:
http://logs.openstack.org/74/467674/2/check/gate-tempest-dsvm-neutron-
full-ubuntu-
xenial/414bb96/logs/screen-n-api.txt.gz?level=TRACE#_May_25_02_46_02_139728
May 25 02:46:02.139728 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api
[req-4a040119-d445-4eb8-8d56-a29653bb6866
tempest-TestVolumeBootPattern-1408924396
tempest-TestVolumeBootPattern-1408924396] Failed BDM validation for volume:
4eb7a1cf-1f6d-4b7c-ae37-99688a0c1e6d
May 25 02:46:02.140058 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api Traceback (most recent call last):
May 25 02:46:02.140638 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/opt/stack/new/nova/nova/compute/api.py", line 1412, in _validate_bdm
May 25 02:46:02.140851 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api context, volume_id, instance)
May 25 02:46:02.141057 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/opt/stack/new/nova/nova/compute/api.py", line 3711, in
_check_attach_and_reserve_volume
May 25 02:46:02.141281 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api instance=instance)
May 25 02:46:02.141487 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/opt/stack/new/nova/nova/volume/cinder.py", line 285, in
check_availability_zone
May 25 02:46:02.141700 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api instance_az =
az.get_instance_availability_zone(context, instance)
May 25 02:46:02.141997 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/opt/stack/new/nova/nova/availability_zones.py", line 167, in
get_instance_availability_zone
May 25 02:46:02.142308 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api host = instance.get('host')
May 25 02:46:02.142540 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line
771, in get
May 25 02:46:02.142762 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api return getattr(self, key)
May 25 02:46:02.142978 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line
67, in getter
May 25 02:46:02.143196 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[17948]: ERROR nova.compute.api self.obj_load_attr(name)
May 25 02:46:02.143414 ubuntu-xenial-infracloud-vanilla-8978830
nova-api[1
[Yahoo-eng-team] [Bug 1692419] Re: Error during Neutron and OVN database sync
It looks like networking-ovn side. ** Also affects: networking-ovn Importance: Undecided Status: New ** Changed in: neutron 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/1692419 Title: Error during Neutron and OVN database sync Status in networking-ovn: New Status in neutron: Invalid Bug description: I have Openstack Ocata deployed from the github and Openvswich OVN for networking. Then neutron server starts and begin database synchroniztion with Openvswich OVN it send error message into neutron log Starting OVN-Northbound DB sync process _sync /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:73 2017-05-22 06:40:47.903 7545 DEBUG networking_ovn.ovn_db_sync [req-589f2abe-079d-43de-b81f-8bd16bb1a821 - - - - -] Address-Set-SYNC: started @ 2017-05-22 06:40:47.903722 sync_address_sets /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:172 2017-05-22 06:40:47.914 7545 DEBUG networking_ovn.ovn_db_sync [-] Starting OVN-Southbound DB sync process _sync /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:703 2017-05-22 06:40:47.915 7545 DEBUG networking_ovn.ovn_db_sync [req-52d9b774-1c60-447b-bdb5-2f32caf89adc - - - - -] OVN-SB Sync hostname and physical networks started sync_hostname_and_physical_networks /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:711 2017-05-22 06:40:47.996 7545 DEBUG networking_ovn.ovn_db_sync [req-52d9b774-1c60-447b-bdb5-2f32caf89adc - - - - -] New host compute2 found in OVN SB DB, but not in Neutron. Add its SegmentHostMapping in Neutron sync_hostname_and_physical_networks /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:725 2017-05-22 06:40:48.002 7545 DEBUG networking_ovn.ovn_db_sync [req-52d9b774-1c60-447b-bdb5-2f32caf89adc - - - - -] OVN-SB Sync hostname and physical networks finished sync_hostname_and_physical_networks /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:737 2017-05-22 06:40:48.003 7545 INFO networking_ovn.l3.l3_ovn [req-52d9b774-1c60-447b-bdb5-2f32caf89adc - - - - -] Getting OvsdbSbOvnIdl 2017-05-22 06:40:48.004 7545 INFO networking_ovn.l3.l3_ovn [req-52d9b774-1c60-447b-bdb5-2f32caf89adc - - - - -] Getting OvsdbNbOvnIdl 2017-05-22 06:40:48.040 7545 DEBUG networking_ovn.ovn_db_sync [req-589f2abe-079d-43de-b81f-8bd16bb1a821 - - - - -] Address_Sets added 0, removed 0, updated 0 sync_address_sets /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:204 2017-05-22 06:40:48.041 7545 DEBUG networking_ovn.ovn_db_sync [req-589f2abe-079d-43de-b81f-8bd16bb1a821 - - - - -] OVN-NB Sync networks, ports and DHCP options started sync_networks_ports_and_dhcp_opts /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:583 2017-05-22 06:40:48.303 7545 DEBUG networking_ovn.ovn_db_sync [req-589f2abe-079d-43de-b81f-8bd16bb1a821 - - - - -] OVN-NB Sync DHCP options for Neutron subnets started _sync_subnet_dhcp_options /usr/lib64/python2.7/site-packages/networking_ovn/ovn_db_sync.py:456 2017-05-22 06:40:48.342 7545 ERROR oslo_db.sqlalchemy.exc_filters [req-589f2abe-079d-43de-b81f-8bd16bb1a821 - - - - -] DBAPIError exception wrapped from (psycopg2.ProgrammingError) operator does not exist: boolean = integer LINE 3: WHERE subnets.enable_dhcp IN (1) ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. [SQL: 'SELECT subnets.project_id AS subnets_project_id, subnets.id AS subnets_id, subnets.name AS subnets_name, subnets.network_id AS subnets_network_id, subnets.segment_id AS subnets_segment_id, subnets.subnetpool_id AS subnets_subnetpool_id, subnets.ip_version AS subnets_ip_version, subnets.cidr AS subnets_cidr, subnets.gateway_ip AS subnets_gateway_ip, subnets.enable_dhcp AS subnets_enable_dhcp, subnets.ipv6_ra_mode AS subnets_ipv6_ra_mode, subnets.ipv6_address_mode AS subnets_ipv6_address_mode, subnets.standard_attr_id AS subnets_standard_attr_id, standardattributes_1.id AS standardattributes_1_id, standardattributes_1.resource_type AS standardattributes_1_resource_type, standardattributes_1.description AS standardattributes_1_description, standardattributes_1.revision_number AS standardattributes_1_revision_number, standardattributes_1.created_at AS standardattributes_1_created_at, standardattributes_1.updated_at AS standardattributes_1_updated_at, subnetpools_1.project_id AS subnetpools_1_project_id, subnetpools_1.id AS subnetpools_1_id, subnetpools_1.name AS subnetpools_1_name, subnetpools_1.ip_version AS subnetpools_1_ip_version, subnetpools_1.default_prefixlen AS subnetpools_1_default_prefixlen, subnetpools_1.min_prefixlen AS subnetpools_1_min_prefixlen, subnetpools_1.max_prefixlen AS subnetpools_1_max_prefixlen, subnetpools_1.shared AS sub
[Yahoo-eng-team] [Bug 1693510] Re: GET /v3/role_assignments?effective&include_names API is blocked with 404 error when a group doesn't exists in identity backend
** Changed in: keystone Milestone: None => pike-1 ** Also affects: keystone/ocata Importance: Undecided Status: New ** Changed in: keystone/ocata Assignee: (unassigned) => prashkre (prashkre) ** Changed in: keystone Importance: Undecided => Low ** Changed in: keystone Importance: Low => Medium ** Changed in: keystone/ocata Importance: Undecided => Medium ** Changed in: keystone/ocata Status: New => In Progress -- 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/1693510 Title: GET /v3/role_assignments?effective&include_names API is blocked with 404 error when a group doesn't exists in identity backend Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: In an environment like ldap server as identity backend, consider ldap group say "fakeGroup2" containing some users is assigned role which insert records in keystone.assignment table. After a while if an admin removes that group from identity backend, role assignment still persists in keystone.assignment table for that group. So when someone invokes [0], in the flow [1] of getting effective role assignments, since group "fakeGroup2" doesn't exits in ldap, it is throwing "Could not find group: fakeGroup2" with 404 error which we need to handle it by displaying other role_assignments instead of NotFound error. [0] GET /v3/role_assignments?effective&include_names&scope.project.id=proj1 [1] https://github.com/openstack/keystone/blob/c3ca06ff47cced16ea9de3d6ef1a6c583bb3cf38/keystone/assignment/core.py#L923 https://github.com/openstack/keystone/blob/c3ca06ff47cced16ea9de3d6ef1a6c583bb3cf38/keystone/assignment/core.py#L839 https://github.com/openstack/keystone/blob/c3ca06ff47cced16ea9de3d6ef1a6c583bb3cf38/keystone/assignment/core.py#L467 >> here it is trying to get the users for each of the ldap group. https://github.com/openstack/keystone/blob/c3ca06ff47cced16ea9de3d6ef1a6c583bb3cf38/keystone/identity/backends/ldap/core.py#L128 https://github.com/openstack/keystone/blob/c3ca06ff47cced16ea9de3d6ef1a6c583bb3cf38/keystone/identity/backends/ldap/core.py#L449 >> since the group is removed from ldap backend, it is throwing exception.GroupNotFound. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1693510/+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 1691001] Re: Unwanted errors in the nova-api.logs
This isn't Neutron issue. ** Changed in: neutron 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/1691001 Title: Unwanted errors in the nova-api.logs Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Bug description: When a user tries to create a security group using the command “ nova secgroup-create ” the execution happens successfully but the user can see some unwanted errors in the nova- api.logs: INFO nova.osapi_compute.wsgi.server "GET /v2/a252bc8e193844d79e83607474ffbff3 HTTP/1.1" status: 404 len: 264 time: 0.5655510 “ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1691001/+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 1693147] Re: XenAPI: nova-compute cannot run when manually delete a VM
Reviewed: https://review.openstack.org/467926
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=92d8103a196c25157295789100117946dcf67304
Submitter: Jenkins
Branch:master
commit 92d8103a196c25157295789100117946dcf67304
Author: Huan Xie
Date: Thu May 25 01:21:31 2017 -0700
XenAPI: nova-compute cannot restart after manually delete VM
When a VM is deleted accidentally (e.g. hardware problem or manually
through the hypervisor rather than Nova), there is a mis-match of
information where the VM is still in nova DB but not the hypervisor.
If we start nova-compute service in this setup, it will fail due to an
untrapped exception when plugging VIFs.
Return an expected exception when Nova cannot find VM via xapi.
Closes-bug: #1693147
Change-Id: I937f5c202c9a4892e8aa56f74fad125791809f8c
** Changed in: nova
Status: In Progress => 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/1693147
Title:
XenAPI: nova-compute cannot run when manually delete a VM
Status in OpenStack Compute (nova):
Fix Released
Bug description:
I have deployed a development DevStack OS environment with
XenServer7.0 and then I did the below steps:
1. Create an instance via Horizon or OpenStack CLI
2. Delete the instance manually (using XenCenter or xe command)
3. Stop nova-compute service and start nova-compute service again
Then I cannot start nova-compute service anymore with errors:
2017-05-24 05:54:09.373 DEBUG nova.compute.manager
[req-97c683b3-cec8-46e6-bb04-d8f17a0b0be8 None None] [instance:
9d5ee1f9-ad88-48d1-b07e-730154ae8cfd] Checking state from (pid=24627)
_get_power_state /opt/stack/nova/nova/compute/manager.py:1169
2017-05-24 05:54:09.380 DEBUG oslo_messaging._drivers.amqpdriver
[req-97c683b3-cec8-46e6-bb04-d8f17a0b0be8 None None] CAST unique_id:
499446a84a51459aad4314c2301e7d08 FANOUT topic 'scheduler' from (pid=24627)
_send
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:478
2017-05-24 05:54:09.383 ERROR oslo_service.service
[req-97c683b3-cec8-46e6-bb04-d8f17a0b0be8 None None] Error starting thread.
2017-05-24 05:54:09.383 TRACE oslo_service.service Traceback (most recent
call last):
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/usr/local/lib/python2.7/dist-packages/oslo_service/service.py", line 721, in
run_service
2017-05-24 05:54:09.383 TRACE oslo_service.service service.start()
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/service.py", line 143, in start
2017-05-24 05:54:09.383 TRACE oslo_service.service self.manager.init_host()
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/compute/manager.py", line 1148, in init_host
2017-05-24 05:54:09.383 TRACE oslo_service.service
self._init_instance(context, instance)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/compute/manager.py", line 945, in _init_instance
2017-05-24 05:54:09.383 TRACE oslo_service.service
self.driver.plug_vifs(instance, net_info)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/virt/xenapi/driver.py", line 309, in plug_vifs
2017-05-24 05:54:09.383 TRACE oslo_service.service
self._vmops.plug_vifs(instance, network_info)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/virt/xenapi/vmops.py", line 1961, in plug_vifs
2017-05-24 05:54:09.383 TRACE oslo_service.service
self.vif_driver.plug(instance, vif, device=device)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/virt/xenapi/vif.py", line 251, in plug
2017-05-24 05:54:09.383 TRACE oslo_service.service vif_ref =
self._get_vif_ref(vif, vm_ref)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/nova/nova/virt/xenapi/vif.py", line 43, in _get_vif_ref
2017-05-24 05:54:09.383 TRACE oslo_service.service vif_refs =
self._session.call_xenapi("VM.get_VIFs", vm_ref)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/os-xenapi/os_xenapi/client/session.py", line 200, in call_xenapi
2017-05-24 05:54:09.383 TRACE oslo_service.service return
session.xenapi_request(method, args)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/opt/stack/os-xenapi/os_xenapi/client/XenAPI.py", line 130, in xenapi_request
2017-05-24 05:54:09.383 TRACE oslo_service.service result =
_parse_result(getattr(self, methodname)(*full_params))
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/usr/lib/python2.7/xmlrpclib.py", line 1243, in _call_
2017-05-24 05:54:09.383 TRACE oslo_service.service return
self._send(self._name, args)
2017-05-24 05:54:09.383 TRACE oslo_service.service File
"/usr/lib/python2.7/xmlrpclib.py", line 1596, in __request
2017-05-24 05:54:09.
[Yahoo-eng-team] [Bug 1693903] Re: Excessive "Deleting stale allocation for instance" warnings in nova-compute logs
Reviewed: https://review.openstack.org/468519 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=590ecfb894a7da0c9a16ab9a60638963a10e48db Submitter: Jenkins Branch:master commit 590ecfb894a7da0c9a16ab9a60638963a10e48db Author: Chris Dent Date: Fri May 26 19:25:18 2017 + Changing deleting stale allocations warning to debug Deleting the allocations is an expected action, and happens frequently so we don't want it to be a warning. It is useful as a piece of debug information, however. Change-Id: Idf88eef036bbe8deca190366f052ab9e355de6e9 Closes-Bug: #1693903 ** Changed in: nova Status: In Progress => 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/1693903 Title: Excessive "Deleting stale allocation for instance" warnings in nova- compute logs Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: New Status in OpenStack Compute (nova) ocata series: New Bug description: I noticed this here: https://review.openstack.org/#/c/460177/12/nova/compute/resource_tracker.py Which is part of a refactor, and that warning actually goes back to newton: https://github.com/openstack/nova/commit/9374566d194be1e861e7d08dd0e3b2a615ff408c It shows up a ton: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Deleting%20stale%20allocation%20for%20instance%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d It shouldn't be a warning. This is when we're deleting resource provider allocations for instances that are being deleted, it's normal operation as far as I can tell. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1693903/+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 1684326] Re: MTU not set on nova instance's vif_type=bridge tap interface
This was fixed with https://review.openstack.org/#/c/458343/ . I put the wrong bug in the commit message. ** Changed in: neutron Status: Confirmed => 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/1684326 Title: MTU not set on nova instance's vif_type=bridge tap interface Status in neutron: Fix Released Bug description: Using linuxbridge with VLAN networks with MTU<>1500, the nova instance's VIF's tap interface's MTU needs to get set to that of the network it's being plugged into, otherwise the first instance on a compute node gets a tap interface (and bridge) with MTU 1500, but the VM tries to do MTU 9000, and frames get dropped. Sequence on first instance launch goes like: * os_vif creates bridge (with initial MTU 1500) * libvirt creates the domain, which creates the tap interface and adds it to the bridge. The tap interface inherits the bridge's MTU of 1500 * The L2 agent notices that a new tap interface showed up, and ensures that the VLAN interface gets added to the bridge - the VLAN interface has MTU 9000 (inherited from the physical interface), but the bridge MTU remains at 1500 - the lowest amongs its member ports (i.e. the tap interface) If that instance is then destroyed, the tap interface goes away, and the bridge updates its MTU to the lowest amongst its members, which is now the VLAN interface - i.e. 9000. A second instance launch then picks up the bridge's MTU of 9000 work works fine. This was previously solved in the l2 agent under https://bugs.launchpad.net/networking-cisco/+bug/1443607, but the solution was reverted in https://git.openstack.org/cgit/openstack/neutron/commit/?id=d352661c56d5f03713e615b7e0c2c9c8688e0132 Re-implementation should probably get the MTU from the neutron network, rather than the VLAN interface. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1684326/+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 1694666] [NEW] metadata service PicklingError: Can't pickle
Public bug reported:
Description
===
Launching an instance causes a lot of error messages in nova-api logs.
The instance is not able to retrieve metadata.
How to reproduce
Deploy nova master branch.
Spawn an instance.
Wait the instance to be active.
In nova-api logs will see error messages.
Expected results
Instance retrieve metadata information
Actual results
==
Instance is not able to retrieve metadata
Environment configuration
=
OpenStack deployed with kolla
Only source images from master fail, binary(rdo or ubuntu packages) works for
now
Affected CentOS, Ubuntu and OracleLinux distributions
Database and memcached works as expected, other services consuming them are not
affected.
Logs
All logs can be found at kolla gates:
Nova: http://logs.openstack.org/73/469373/1/check/gate-kolla-ansible-
dsvm-deploy-centos-source-centos-7-nv/8cecb36/logs/kolla/nova/
Neutron: http://logs.openstack.org/73/469373/1/check/gate-kolla-ansible-
dsvm-deploy-centos-source-centos-7-nv/8cecb36/logs/kolla/neutron/
Related errors:
Nova API:
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler
[req-3daa8e91-93e5-4676-b77a-048ad3dd53d2 - - - - -] Failed to get metadata for
instance id: 8cbd067f-8cd6-4365-b299-3ffc146d0790
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler Traceback (most
recent call last):
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/nova/api/metadata/handler.py",
line 285, in _get_meta_by_instance_id
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler remote_address)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/nova/api/metadata/handler.py",
line 87, in get_metadata_by_instance_id
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler
self._cache.set(cache_key, data)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/nova/cache_utils.py", line
116, in set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler return
self.region.set(key, value)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/dogpile/cache/region.py", line
973, in set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler
self.backend.set(key, self._value(value))
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/dogpile/cache/backends/memcached.py",
line 178, in set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler
**self.set_arguments
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_cache/backends/memcache_pool.py",
line 32, in _run_method
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler return
getattr(client, __name)(*args, **kwargs)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/memcache.py", line 740, in set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler return
self._set("set", key, val, time, min_compress_len, noreply)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/memcache.py", line 1060, in
_set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler return
_unsafe_set()
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/memcache.py", line 1034, in
_unsafe_set
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler store_info =
self._val_to_store_info(val, min_compress_len)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler File
"/var/lib/kolla/venv/lib/python2.7/site-packages/memcache.py", line 998, in
_val_to_store_info
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler pickler.dump(val)
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler PicklingError: Can't
pickle : it's not the same object as
sqlalchemy.orm.session.Session
2017-05-31 09:09:34.703 31 ERROR nova.api.metadata.handler
Neutron metadata:
2017-05-31 09:09:24.985 23 DEBUG neutron.agent.metadata.agent [-] Request: GET
/2009-04-04/meta-data/instance-id HTTP/1.0
Accept: */*
Connection: close
Content-Type: text/plain
Host: 169.254.169.254
User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 OpenSSL/1.0.0j
zlib/1.2.6
X-Forwarded-For: 10.0.0.5
X-Neutron-Network-Id: 50395d7c-fcc6-4aef-afdc-931c4573b0d1 __call__
/var/lib/kolla/venv/lib/python2.7/site-packages/neutron/agent/metadata/agent.py:86
2017-05-31 09:09:25.269 23 WARNING neutron.agent.metadata.agent [-] Remote
metadata server experienced an internal server error.
2017-05-31 09:09:25.269 23 INFO eventlet.wsgi.server [-] 10.0.0.5, "GET
/2009-04-04/meta-data/
[Yahoo-eng-team] [Bug 1693166] Re: keystone federation auth
** Changed in: keystone
Status: In Progress => 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/1693166
Title:
keystone federation auth
Status in OpenStack Identity (keystone):
Invalid
Bug description:
When I create a mapping with rule as following:
[
{
"local": [
{
"group": {
"name": "group1",
"domain": {
"name": "domain1"
}
}
}
],
"remote": [
{
"type": "openstack_user"
},
{
"type": "openstack_user_domain"
}
]
}
]
I have an idp user, and I got the assertion and now I want to GET GET
v3/OS-FEDERATION/identity_providers/keystone-idp/protocols/saml2/auth,
Error happens like:
keystoneauth1.exceptions.http.InternalServerError: An unexpected error
prevented the server from fulfilling your request. (HTTP 500)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1693166/+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 1694636] [NEW] Instance enters error state in case of unavailable live migration destinations
Public bug reported: We check whether shared storage is used before live migrating instances. If the vm disks storage location is unavailable, we'll propagate an OSError instead of a MigrationPreCheckError exception. For this reason, we prevent Nova from trying a different compute node. Trace: http://paste.openstack.org/show/611003/ ** Affects: compute-hyperv Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Tags: hyper-v ** Also affects: nova Importance: Undecided Status: New ** Tags added: hyper-v -- 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/1694636 Title: Instance enters error state in case of unavailable live migration destinations Status in compute-hyperv: New Status in OpenStack Compute (nova): New Bug description: We check whether shared storage is used before live migrating instances. If the vm disks storage location is unavailable, we'll propagate an OSError instead of a MigrationPreCheckError exception. For this reason, we prevent Nova from trying a different compute node. Trace: http://paste.openstack.org/show/611003/ To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1694636/+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 1694614] [NEW] Docs job on jenkins failing
Public bug reported: I see failed gate-neutron-docs-ubuntu-xenial in many jobs since yesterday. It always fails with error like e.g. in http://logs.openstack.org/60/469260/2/check/gate-neutron-docs-ubuntu- xenial/e55b579/console.html#_2017-05-30_22_18_04_277430 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1694614 Title: Docs job on jenkins failing Status in neutron: New Bug description: I see failed gate-neutron-docs-ubuntu-xenial in many jobs since yesterday. It always fails with error like e.g. in http://logs.openstack.org/60/469260/2/check/gate-neutron-docs-ubuntu- xenial/e55b579/console.html#_2017-05-30_22_18_04_277430 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694614/+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
