[Yahoo-eng-team] [Bug 1285478] Re: Enforce alphabetical ordering in requirements file
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) = ChenZheng (chen-zheng) ** Changed in: python-heatclient Assignee: ChangBo Guo(gcb) (glongwave) = ChenZheng (chen-zheng) ** Changed in: python-glanceclient Assignee: ChangBo Guo(gcb) (glongwave) = ChenZheng (chen-zheng) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285478 Title: Enforce alphabetical ordering in requirements file Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (Keystone): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: New Status in Python client library for Keystone: New Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Python client library for Swift: New Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in OpenStack Object Storage (Swift): New Status in Tempest: In Progress Status in Trove - Database as a Service: New Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1285478/+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 1277104] Re: wrong order of assertEquals args
** Also affects: nova Importance: Undecided Status: New ** Also affects: cinder 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/1277104 Title: wrong order of assertEquals args Status in OpenStack Telemetry (Ceilometer): In Progress Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Compute (Nova): New Status in Python client library for Glance: In Progress Status in Python client library for Ironic: New Status in Python client library for Nova: In Progress Status in Python client library for Swift: In Progress Bug description: Args of assertEquals method in ceilometer.tests are arranged in wrong order. In result when test fails it shows incorrect information about observed and actual data. It's found more than 2000 times. Right order of arguments is expected, actual. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1277104/+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 1285547] [NEW] Add nova cell-list to python-novaclient
Public bug reported: Now only nova-manager cell list but no nova cell-list, it is better that we add nova cell-list as nova sub command as most of users are using nova command. ** Affects: python-novaclient Importance: Undecided Assignee: Jay Lau (jay-lau-513) Status: New ** Project changed: nova = python-novaclient ** Changed in: python-novaclient Assignee: (unassigned) = Jay Lau (jay-lau-513) -- 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/1285547 Title: Add nova cell-list to python-novaclient Status in Python client library for Nova: New Bug description: Now only nova-manager cell list but no nova cell-list, it is better that we add nova cell-list as nova sub command as most of users are using nova command. To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1285547/+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 1285530] Re: exception message should use gettextutils
** Changed in: neutron Assignee: (unassigned) = Yongli He (yongli-he) ** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Assignee: (unassigned) = Yongli He (yongli-he) ** Also affects: tuskar Importance: Undecided Status: New ** Changed in: tuskar Assignee: (unassigned) = Yongli He (yongli-he) ** Changed in: nova Status: In Progress = New ** Also affects: tuskar-ui Importance: Undecided Status: New ** Changed in: tuskar-ui Assignee: (unassigned) = Yongli He (yongli-he) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285530 Title: exception message should use gettextutils Status in Cinder: New Status in Ironic (Bare Metal Provisioning): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in OpenStack Object Storage (Swift): New Status in Tuskar: In Progress Status in Tuskar UI: In Progress Bug description: What To Translate At present the convention is to translate all user-facing strings. This means API messages, CLI responses, documentation, help text, etc. There has been a lack of consensus about the translation of log messages; the current ruling is that while it is not against policy to mark log messages for translation if your project feels strongly about it, translating log messages is not actively encouraged. Exception text should not be marked for translation, becuase if an exception occurs there is no guarantee that the translation machinery will be functional. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285530/+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 1285530] Re: exception message should use gettextutils
** Also affects: ironic Importance: Undecided Status: New ** Changed in: ironic Assignee: (unassigned) = Yongli He (yongli-he) ** Also affects: swift Importance: Undecided Status: New ** Changed in: swift Assignee: (unassigned) = Yongli He (yongli-he) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285530 Title: exception message should use gettextutils Status in Cinder: New Status in Ironic (Bare Metal Provisioning): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Python client library for Ironic: New Status in Python client library for Neutron: In Progress Status in OpenStack Object Storage (Swift): In Progress Status in Tuskar: In Progress Status in Tuskar UI: In Progress Bug description: What To Translate At present the convention is to translate all user-facing strings. This means API messages, CLI responses, documentation, help text, etc. There has been a lack of consensus about the translation of log messages; the current ruling is that while it is not against policy to mark log messages for translation if your project feels strongly about it, translating log messages is not actively encouraged. Exception text should not be marked for translation, becuase if an exception occurs there is no guarantee that the translation machinery will be functional. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285530/+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 1285530] Re: exception message should use gettextutils
** Also affects: python-ironicclient Importance: Undecided Status: New ** Changed in: python-ironicclient Assignee: (unassigned) = Yongli He (yongli-he) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285530 Title: exception message should use gettextutils Status in Cinder: New Status in Ironic (Bare Metal Provisioning): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: In Progress Status in OpenStack Object Storage (Swift): In Progress Status in Tuskar: In Progress Status in Tuskar UI: In Progress Bug description: What To Translate At present the convention is to translate all user-facing strings. This means API messages, CLI responses, documentation, help text, etc. There has been a lack of consensus about the translation of log messages; the current ruling is that while it is not against policy to mark log messages for translation if your project feels strongly about it, translating log messages is not actively encouraged. Exception text should not be marked for translation, becuase if an exception occurs there is no guarantee that the translation machinery will be functional. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285530/+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 1285530] Re: exception message should use gettextutils
** Also affects: python-neutronclient 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/1285530 Title: exception message should use gettextutils Status in Cinder: New Status in Ironic (Bare Metal Provisioning): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: In Progress Status in OpenStack Object Storage (Swift): In Progress Status in Tuskar: In Progress Status in Tuskar UI: In Progress Bug description: What To Translate At present the convention is to translate all user-facing strings. This means API messages, CLI responses, documentation, help text, etc. There has been a lack of consensus about the translation of log messages; the current ruling is that while it is not against policy to mark log messages for translation if your project feels strongly about it, translating log messages is not actively encouraged. Exception text should not be marked for translation, becuase if an exception occurs there is no guarantee that the translation machinery will be functional. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285530/+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 1285598] [NEW] tempest failure: test_security_groups_basic_ops failes with MismatchError
Public bug reported: Jenkins job 'check-tempest-dsvm-neutron' failed. http://logs.openstack.org/24/74124/3/check/check-tempest-dsvm-neutron/b7488b4/logs/testr_results.html.gz Failed test is as follows: --- Traceback (most recent call last): File tempest/scenario/test_security_groups_basic_ops.py, line 168, in setUp self._verify_mac_addr(self.primary_tenant) File tempest/scenario/test_security_groups_basic_ops.py, line 456, in _verify_mac_addr self.assertIn((subnet_id, server_ip, mac_addr), port_detail_list) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in assertIn self.assertThat(haystack, Contains(needle)) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 406, in assertThat raise mismatch_error MismatchError: (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', None, 'fa:16:3e:a0:a9:f8') not in [(u'94bee2b4-b5a7-4465-8221-d97f8ba098a6', u'10.100.0.1', u'fa:16:3e:2e:ab:ca'), (u'94bee2b4-b5a7-4465-8221-d97f8ba098a6', u'10.100.0.2', u'fa:16:3e:e3:0c:03'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.3', u'fa:16:3e:4f:4b:c4'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.2', u'fa:16:3e:9d:87:dc'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.9', u'fa:16:3e:18:0d:5b'), (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', u'10.100.0.19', u'fa:16:3e:34:9a:af'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.1', u'fa:16:3e:5d:81:e2'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.8', u'fa:16:3e:8b:49:d4'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.34', u'fa:16:3e:62:c8:6e'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.3', u'fa:16:3e:2d:8c:34'), (u'8848e40b-515d-498a-9fd7-9173f333bf86', u'10.100.0.1', u'fa:16:3e:6b:50:a9'), (u'0ac4d00d-502f-4412-9107-826 504c5c032', u'172.24.4.36', u'fa:16:3e:9b:16:10'), (u'5d10320c-d47d-4b30-814b-69539dca4074', u'10.100.0.2', u'fa:16:3e:e9:df:6c'), (u'79363d87-0c23-4d70-9770-35270201946e', u'10.100.0.1', u'fa:16:3e:5e:45:0a'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.2', u'fa:16:3e:99:7d:3b'), (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', u'10.100.0.18', u'fa:16:3e:a0:a9:f8'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.35', u'fa:16:3e:6e:ac:cc'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.37', u'fa:16:3e:7a:46:04'), (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', u'10.100.0.17', u'fa:16:3e:0c:06:35'), (u'5d10320c-d47d-4b30-814b-69539dca4074', u'10.100.0.1', u'fa:16:3e:93:b3:de')] --- It seems this happens occasionally. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiX3ZlcmlmeV9tYWNfYWRkclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxMzkzNDk3NTEwNjYwfQ== ** 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/1285598 Title: tempest failure: test_security_groups_basic_ops failes with MismatchError Status in OpenStack Neutron (virtual network service): New Bug description: Jenkins job 'check-tempest-dsvm-neutron' failed. http://logs.openstack.org/24/74124/3/check/check-tempest-dsvm-neutron/b7488b4/logs/testr_results.html.gz Failed test is as follows: --- Traceback (most recent call last): File tempest/scenario/test_security_groups_basic_ops.py, line 168, in setUp self._verify_mac_addr(self.primary_tenant) File tempest/scenario/test_security_groups_basic_ops.py, line 456, in _verify_mac_addr self.assertIn((subnet_id, server_ip, mac_addr), port_detail_list) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in assertIn self.assertThat(haystack, Contains(needle)) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 406, in assertThat raise mismatch_error MismatchError: (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', None, 'fa:16:3e:a0:a9:f8') not in [(u'94bee2b4-b5a7-4465-8221-d97f8ba098a6', u'10.100.0.1', u'fa:16:3e:2e:ab:ca'), (u'94bee2b4-b5a7-4465-8221-d97f8ba098a6', u'10.100.0.2', u'fa:16:3e:e3:0c:03'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.3', u'fa:16:3e:4f:4b:c4'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.2', u'fa:16:3e:9d:87:dc'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.9', u'fa:16:3e:18:0d:5b'), (u'5fc23b6b-14e0-480f-b766-5b6dbc670aa6', u'10.100.0.19', u'fa:16:3e:34:9a:af'), (u'ffca826c-0bfe-46ef-9090-00f29e3bc6d6', u'10.1.0.1', u'fa:16:3e:5d:81:e2'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.8', u'fa:16:3e:8b:49:d4'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.34', u'fa:16:3e:62:c8:6e'), (u'0ac4d00d-502f-4412-9107-826504c5c032', u'172.24.4.3', u'fa:16:3e:2d:8c:34'), (u'8848e40b-515d-498a-9fd7-9173f333bf86', u'10.100.0.1', u'fa:16:3e:6b:50:a9'), (u'0ac4d00d-502f-4412-9107-8
[Yahoo-eng-team] [Bug 1285617] [NEW] sample configuration needs to be updated for database config
Public bug reported: As reported on the mailing list, sample configuration files are out of date with respect to database configuration. http://lists.openstack.org/pipermail/openstack- dev/2014-February/028394.html they lack the [database] stanza and still have sql_connection. ** Affects: glance Importance: Undecided Status: Confirmed ** Changed in: glance Status: New = Confirmed ** Summary changed: - sample configuration needs to be update for database config + sample configuration needs to be updated for database config -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1285617 Title: sample configuration needs to be updated for database config Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Bug description: As reported on the mailing list, sample configuration files are out of date with respect to database configuration. http://lists.openstack.org/pipermail/openstack- dev/2014-February/028394.html they lack the [database] stanza and still have sql_connection. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1285617/+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 1285621] [NEW] external network not available
Public bug reported: the external network suddenly disappeared from the floating ips pools and the regular user with the role member can't allocate ips now only admins can do. I am using Havana and disabling the shared option in external network so that the user don't lunch instance using it. the external network doesn't appear on dashboard and APIs and this is a sudden change. I tried in a new installation privately on two servers using rdo and the new installation have the same problem and it's something weird. there is an old project I was working on at a site I checked it I found that every things working fine. I checked the policy.json and things are fine. ** Affects: neutron Importance: Undecided Status: New ** Tags: external havana neutron-core ports -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285621 Title: external network not available Status in OpenStack Neutron (virtual network service): New Bug description: the external network suddenly disappeared from the floating ips pools and the regular user with the role member can't allocate ips now only admins can do. I am using Havana and disabling the shared option in external network so that the user don't lunch instance using it. the external network doesn't appear on dashboard and APIs and this is a sudden change. I tried in a new installation privately on two servers using rdo and the new installation have the same problem and it's something weird. there is an old project I was working on at a site I checked it I found that every things working fine. I checked the policy.json and things are fine. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1285621/+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 1285478] Re: Enforce alphabetical ordering in requirements file
** No longer affects: python-keystoneclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285478 Title: Enforce alphabetical ordering in requirements file Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (Keystone): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: New Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Python client library for Swift: New Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in OpenStack Object Storage (Swift): New Status in Tempest: In Progress Status in Trove - Database as a Service: New Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1285478/+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 1256344] Re: jsonschema min_version requirements are not sufficient
I think this bug can be closed as I don't see this any more. ** Changed in: nova Status: In Progress = 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/1256344 Title: jsonschema min_version requirements are not sufficient Status in OpenStack Compute (Nova): Invalid Bug description: The unit tests are failing with the current min_version for jsonschema==1.3.0. This is due to the following reason: validators is a 'dict' in 1.3.0 so there's no extend method. In 2.0.0 it's a class with extend method defined. So it's better to update min_version to 2.0.0. The errors seen are: == FAIL: nova.tests.test_api_validation.AdditionalPropertiesDisableTestCase.test_validate_additionalProperties_disable -- _StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py, line 133, in setUp @validation.schema(request_body_schema=schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/__init__.py, line 36, in schema schema_validator = _SchemaValidator(request_body_schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/validators.py, line 51, in __init__ validator_cls = jsonschema.validators.extend(self.validator_org, AttributeError: 'dict' object has no attribute 'extend' == FAIL: nova.tests.test_api_validation.AdditionalPropertiesEnableTestCase.test_validate_additionalProperties_enable -- _StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py, line 106, in setUp @validation.schema(request_body_schema=schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/__init__.py, line 36, in schema schema_validator = _SchemaValidator(request_body_schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/validators.py, line 51, in __init__ validator_cls = jsonschema.validators.extend(self.validator_org, AttributeError: 'dict' object has no attribute 'extend' == FAIL: nova.tests.test_api_validation.IntegerRangeTestCase.test_validate_integer_range -- _StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py, line 302, in setUp @validation.schema(request_body_schema=schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/__init__.py, line 36, in schema schema_validator = _SchemaValidator(request_body_schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/validators.py, line 51, in __init__ validator_cls = jsonschema.validators.extend(self.validator_org, AttributeError: 'dict' object has no attribute 'extend' == FAIL: nova.tests.test_api_validation.IntegerTestCase.test_validate_integer -- _StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py, line 245, in setUp @validation.schema(request_body_schema=schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/__init__.py, line 36, in schema schema_validator = _SchemaValidator(request_body_schema) File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/validators.py, line 51, in __init__ validator_cls = jsonschema.validators.extend(self.validator_org, AttributeError: 'dict' object has no attribute 'extend' == FAIL: nova.tests.test_api_validation.StringLengthTestCase.test_validate_string_length -- _StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File /tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py, line 207, in setUp @validation.schema(request_body_schema=schema) File
[Yahoo-eng-team] [Bug 1285641] [NEW] different fully qualified class name for VPNaaS migrations
Public bug reported: In migrations 52ff27f7567a_support_for_vpnaas.py and 338d7508968c_vpnaas_peer_address_.py different class names are set: neutron.services.vpn.plugin.VPNDriverPlugin and neutron.services.vpn.plugin.VPNPlugin. This cause the following exception: neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head No handlers could be found for logger neutron.common.legacy INFO [alembic.migration] Context impl MySQLImpl. INFO [alembic.migration] Will assume non-transactional DDL. INFO [alembic.migration] Running upgrade None - folsom, folsom initial database INFO [alembic.migration] Running upgrade folsom - 2c4af419145b, l3_support INFO [alembic.migration] Running upgrade 2c4af419145b - 5a875d0e5c, ryu INFO [alembic.migration] Running upgrade 5a875d0e5c - 48b6f43f7471, DB support for service types INFO [alembic.migration] Running upgrade 48b6f43f7471 - 3cb5d900c5de, security_groups INFO [alembic.migration] Running upgrade 3cb5d900c5de - 1d76643bcec4, nvp_netbinding INFO [alembic.migration] Running upgrade 1d76643bcec4 - 2a6d0b51f4bb, cisco plugin cleanup INFO [alembic.migration] Running upgrade 2a6d0b51f4bb - 1b693c095aa3, Quota ext support added in Grizzly INFO [alembic.migration] Running upgrade 1b693c095aa3 - 1149d7de0cfa, initial port security INFO [alembic.migration] Running upgrade 1149d7de0cfa - 49332180ca96, ryu plugin update INFO [alembic.migration] Running upgrade 49332180ca96 - 38335592a0dc, nvp_portmap INFO [alembic.migration] Running upgrade 38335592a0dc - 54c2c487e913, 'DB support for load balancing service INFO [alembic.migration] Running upgrade 54c2c487e913 - 45680af419f9, nvp_qos INFO [alembic.migration] Running upgrade 45680af419f9 - 1c33fa3cd1a1, Support routing table configuration on Router INFO [alembic.migration] Running upgrade 1c33fa3cd1a1 - 363468ac592c, nvp_network_gw INFO [alembic.migration] Running upgrade 363468ac592c - 511471cc46b, Add agent management extension model support INFO [alembic.migration] Running upgrade 511471cc46b - 3b54bf9e29f7, NEC plugin sharednet INFO [alembic.migration] Running upgrade 3b54bf9e29f7 - 4692d074d587, agent scheduler INFO [alembic.migration] Running upgrade 4692d074d587 - 1341ed32cc1e, nvp_net_binding INFO [alembic.migration] Running upgrade 1341ed32cc1e - grizzly, grizzly INFO [alembic.migration] Running upgrade grizzly - f489cf14a79c, DB support for load balancing service (havana) INFO [alembic.migration] Running upgrade f489cf14a79c - 176a85fc7d79, Add portbindings db INFO [alembic.migration] Running upgrade 176a85fc7d79 - 32b517556ec9, remove TunnelIP model INFO [alembic.migration] Running upgrade 32b517556ec9 - 128e042a2b68, ext_gw_mode INFO [alembic.migration] Running upgrade 128e042a2b68 - 5ac71e65402c, ml2_initial INFO [alembic.migration] Running upgrade 5ac71e65402c - 3cbf70257c28, nvp_mac_learning INFO [alembic.migration] Running upgrade 3cbf70257c28 - 5918cbddab04, add tables for router rules support INFO [alembic.migration] Running upgrade 5918cbddab04 - 3cabb850f4a5, Table to track port to host associations INFO [alembic.migration] Running upgrade 3cabb850f4a5 - b7a8863760e, Remove cisco_vlan_bindings table INFO [alembic.migration] Running upgrade b7a8863760e - 13de305df56e, nec_add_pf_name INFO [alembic.migration] Running upgrade 13de305df56e - 20ae61555e95, DB Migration for ML2 GRE Type Driver INFO [alembic.migration] Running upgrade 20ae61555e95 - 477a4488d3f4, DB Migration for ML2 VXLAN Type Driver INFO [alembic.migration] Running upgrade 477a4488d3f4 - 2032abe8edac, LBaaS add status description INFO [alembic.migration] Running upgrade 2032abe8edac - 52c5e4a18807, LBaaS Pool scheduler INFO [alembic.migration] Running upgrade 52c5e4a18807 - 557edfc53098, New service types framework (service providers) INFO [alembic.migration] Running upgrade 557edfc53098 - e6b16a30d97, Add cisco_provider_networks table INFO [alembic.migration] Running upgrade e6b16a30d97 - 39cf3f799352, FWaaS Havana-2 model INFO [alembic.migration] Running upgrade 39cf3f799352 - 52ff27f7567a, Support for VPNaaS INFO [alembic.migration] Running upgrade 52ff27f7567a - 11c6e18605c8, Pool Monitor status field INFO [alembic.migration] Running upgrade 11c6e18605c8 - 35c7c198ddea, remove status from HealthMonitor INFO [alembic.migration] Running upgrade 35c7c198ddea - 263772d65691, Cisco plugin db cleanup part II INFO [alembic.migration] Running upgrade 263772d65691 - c88b6b5fea3, Cisco N1KV tables INFO [alembic.migration] Running upgrade c88b6b5fea3 - f9263d6df56, remove_dhcp_lease INFO [alembic.migration] Running upgrade f9263d6df56 - 569e98a8132b, metering INFO [alembic.migration] Running upgrade 569e98a8132b - 86cf4d88bd3, remove bigswitch port tracking table INFO [alembic.migration] Running upgrade 86cf4d88bd3 - 3c6e57a23db4, add multiprovider INFO [alembic.migration] Running upgrade 3c6e57a23db4
[Yahoo-eng-team] [Bug 1285686] [NEW] AltCloud: Do not run dmidecode on arm32/64
Public bug reported: This is a follow-up to this SmartOS change: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/957 It seems to me that we shouldn't run dmidecode on arm in AltCloud as well and do something like: http://bazaar.launchpad.net/~strikov/cloud-init/altcloud-dmidecode-fix/revision/959 I put this check for arm to get_cloud_type() not get_data() to avoid blocking of CLOUD_INFO_FILE path on arm. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1285686 Title: AltCloud: Do not run dmidecode on arm32/64 Status in Init scripts for use on cloud images: New Bug description: This is a follow-up to this SmartOS change: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/957 It seems to me that we shouldn't run dmidecode on arm in AltCloud as well and do something like: http://bazaar.launchpad.net/~strikov/cloud-init/altcloud-dmidecode-fix/revision/959 I put this check for arm to get_cloud_type() not get_data() to avoid blocking of CLOUD_INFO_FILE path on arm. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1285686/+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 1285308] Re: commit da11e62216ffb219bcfe30fc647a49ebbb403bb3 in the python-novaclient repo removes the add_arg function from the utils module, which breaks os_diskconfig_python_n
This looks like a bug in a rackspaces third party plugin (https://github.com/rackerlabs/os_diskconfig_python_novaclient_ext/blob/master/os_diskconfig_python_novaclient_ext/__init__.py) that we do not support upstream. I had no idea that it existed until two minutes ago. ** 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/1285308 Title: commit da11e62216ffb219bcfe30fc647a49ebbb403bb3 in the python- novaclient repo removes the add_arg function from the utils module, which breaks os_diskconfig_python_novaclient_ext Status in OpenStack Compute (Nova): Invalid Bug description: It appears that removing the add_arg function from utils module breaks components that depend on it, such as os-diskconfig-python-novaclient- ext To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1285308/+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 1282514] Re: python 3 only has __self__, the im_self should be replace by __self_
nova isn't python 3 compatible yet primarily due to incompatible dependencies, until we have a roadmap and a timeline to fix those I see little value in making nova itself python 3 compatible. It will just cause unnecessary churn that is hard to gate on. ** Changed in: nova Status: In Progress = 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/1282514 Title: python 3 only has __self__, the im_self should be replace by __self_ Status in Cinder: In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Compute (Nova): Invalid Status in Oslo - a Library of Common OpenStack Code: In Progress Status in Tuskar: In Progress Bug description: for code compatible with Python 3, we should use the __self__ instead of im_self. for example : cinder/volume/flows/common.py def make_pretty_name(method): Makes a pretty name for a function/method. meth_pieces = [method.__name__] # If its an instance method attempt to tack on the class name if hasattr(method, 'im_self') and method.im_self is not None: try: meth_pieces.insert(0, method.im_self.__class__.__name__) except AttributeError: pass return ..join(meth_pieces) For reference here(thanks Alex for adding this): Changed in version 2.6: For Python 3 forward-compatibility, im_func is also available as __func__, and im_self as __self__. http://docs.python.org/2/reference/datamodel.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1282514/+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 1285735] [NEW] libvirt lvm volumes based on instance['name'] not instance['uuid']
Public bug reported: because libvirt lvm volumes are based on instance['name'], it means that the actual names used in lvm storage are based on an operator configuration variable: instance_name_template the default is 'instance-%08x' however this is site changable, and changable at any time. This creates 2 failure modes. #1) operator changes this, the result is all volumes created before the change are no longer able to be cleaned up by nova #2) operator has changed this to something that includes end user input, like %(display_name), which would allow one user to impact another (use A has display name bob, user B has displayname bob_joe) because of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1068 specifically: pattern = '%s_' % instance['name'] def belongs_to_instance(disk): return disk.startswith(pattern) #2 is a non default situation, and requires specific config by an adminstrator and specific naming by users, but it should be protected against. A much better approach would be to use instance['uuid'] which has no operator or user impact on naming. ** Affects: nova Importance: High Assignee: Sean Dague (sdague) Status: New ** Tags: libvirt volumes ** Changed in: nova Importance: Undecided = High -- 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/1285735 Title: libvirt lvm volumes based on instance['name'] not instance['uuid'] Status in OpenStack Compute (Nova): New Bug description: because libvirt lvm volumes are based on instance['name'], it means that the actual names used in lvm storage are based on an operator configuration variable: instance_name_template the default is 'instance-%08x' however this is site changable, and changable at any time. This creates 2 failure modes. #1) operator changes this, the result is all volumes created before the change are no longer able to be cleaned up by nova #2) operator has changed this to something that includes end user input, like %(display_name), which would allow one user to impact another (use A has display name bob, user B has displayname bob_joe) because of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1068 specifically: pattern = '%s_' % instance['name'] def belongs_to_instance(disk): return disk.startswith(pattern) #2 is a non default situation, and requires specific config by an adminstrator and specific naming by users, but it should be protected against. A much better approach would be to use instance['uuid'] which has no operator or user impact on naming. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1285735/+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 1285831] [NEW] Error in horizon.less file
Public bug reported: File openstack_dashboard/static/dashboard/less/horizon.less Line 190: } border-bottom-left-radius :.2em; == border-bottom-left-radius: .2em; ** Affects: horizon Importance: Undecided Assignee: Arash Eghtesadi (aeghtesadi) Status: In Progress -- 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/1285831 Title: Error in horizon.less file Status in OpenStack Dashboard (Horizon): In Progress Bug description: File openstack_dashboard/static/dashboard/less/horizon.less Line 190: } border-bottom-left-radius :.2em; == border-bottom-left-radius: .2em; To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1285831/+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 1285833] [NEW] CertificateConfigError: Unable to load certificate. Ensure your system is configured properly
Public bug reported: DEBUG keystoneclient.middleware.auth_token [-] Token validation failure. _validate_user_token /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py:849 TRACE keystoneclient.middleware.auth_token Traceback (most recent call last): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 836, in _validate_user_token TRACE keystoneclient.middleware.auth_token verified = self.verify_signed_token(user_token) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1275, in verify_signed_token TRACE keystoneclient.middleware.auth_token if self.is_signed_token_revoked(signed_text): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1233, in is_signed_token_revoked TRACE keystoneclient.middleware.auth_token revocation_list = self.token_revocation_list TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1329, in token_revocation_list TRACE keystoneclient.middleware.auth_token self.token_revocation_list = self.fetch_revocation_list() TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1366, in fetch_revocation_list TRACE keystoneclient.middleware.auth_token return self.cms_verify(data['signed']) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1257, in cms_verify TRACE keystoneclient.middleware.auth_token self.signing_ca_file_name) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/common/cms.py, line 134, in cms_verify TRACE keystoneclient.middleware.auth_token raise exceptions.CertificateConfigError(err) TRACE keystoneclient.middleware.auth_token CertificateConfigError: Unable to load certificate. Ensure your system is configured properly. TRACE keystoneclient.middleware.auth_token DEBUG keystoneclient.middleware.auth_token [-] Marking token a961b45e3f117dd58b4afc6564d556fa as unauthorized in memcache _cache_store_invalid /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py:1170 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token a961b45e3f117dd58b4afc6564d556fa INFO keystoneclient.middleware.auth_token [-] Invalid user token - rejecting request INFO eventlet.wsgi.server [-] 127.0.0.1 - - [27/Feb/2014 16:50:36] POST /v1/4ef47f119bc04d6dae054a5035359641/volumes HTTP/1.1 401 191 0.299349 http://logs.openstack.org/35/75535/1/gate/gate-grenade- dsvm/3c8e07e/logs/new/screen-c-api.txt.gz?#_2014-02-27_16_50_36_158 logstash query: message:CertificateConfigError: Unable to load certificate. Ensure your system is configured properly. AND NOT filename:logs/screen-n-api.txt ** Affects: cinder Importance: Undecided Status: Confirmed ** Affects: heat Importance: Undecided Status: New ** Affects: keystone Importance: Undecided Status: New ** Tags: gate-failure ** Also affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1285833 Title: CertificateConfigError: Unable to load certificate. Ensure your system is configured properly Status in Cinder: Confirmed Status in Orchestration API (Heat): New Status in OpenStack Identity (Keystone): New Bug description: DEBUG keystoneclient.middleware.auth_token [-] Token validation failure. _validate_user_token /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py:849 TRACE keystoneclient.middleware.auth_token Traceback (most recent call last): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 836, in _validate_user_token TRACE keystoneclient.middleware.auth_token verified = self.verify_signed_token(user_token) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1275, in verify_signed_token TRACE keystoneclient.middleware.auth_token if self.is_signed_token_revoked(signed_text): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1233, in is_signed_token_revoked TRACE keystoneclient.middleware.auth_token revocation_list = self.token_revocation_list TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line
[Yahoo-eng-team] [Bug 1285833] Re: CertificateConfigError: Unable to load certificate. Ensure your system is configured properly
From logstash this started showing around 2/23. It also hits heat: http://logs.openstack.org/55/59655/23/check/check-tempest-dsvm-postgres- full/5684a8a/logs/screen-h-api.txt e-r query patch here: https://review.openstack.org/#/c/76948/ ** Also affects: heat Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1285833 Title: CertificateConfigError: Unable to load certificate. Ensure your system is configured properly Status in Cinder: Confirmed Status in Orchestration API (Heat): New Status in OpenStack Identity (Keystone): New Bug description: DEBUG keystoneclient.middleware.auth_token [-] Token validation failure. _validate_user_token /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py:849 TRACE keystoneclient.middleware.auth_token Traceback (most recent call last): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 836, in _validate_user_token TRACE keystoneclient.middleware.auth_token verified = self.verify_signed_token(user_token) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1275, in verify_signed_token TRACE keystoneclient.middleware.auth_token if self.is_signed_token_revoked(signed_text): TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1233, in is_signed_token_revoked TRACE keystoneclient.middleware.auth_token revocation_list = self.token_revocation_list TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1329, in token_revocation_list TRACE keystoneclient.middleware.auth_token self.token_revocation_list = self.fetch_revocation_list() TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1366, in fetch_revocation_list TRACE keystoneclient.middleware.auth_token return self.cms_verify(data['signed']) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 1257, in cms_verify TRACE keystoneclient.middleware.auth_token self.signing_ca_file_name) TRACE keystoneclient.middleware.auth_token File /opt/stack/new/python-keystoneclient/keystoneclient/common/cms.py, line 134, in cms_verify TRACE keystoneclient.middleware.auth_token raise exceptions.CertificateConfigError(err) TRACE keystoneclient.middleware.auth_token CertificateConfigError: Unable to load certificate. Ensure your system is configured properly. TRACE keystoneclient.middleware.auth_token DEBUG keystoneclient.middleware.auth_token [-] Marking token a961b45e3f117dd58b4afc6564d556fa as unauthorized in memcache _cache_store_invalid /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py:1170 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token a961b45e3f117dd58b4afc6564d556fa INFO keystoneclient.middleware.auth_token [-] Invalid user token - rejecting request INFO eventlet.wsgi.server [-] 127.0.0.1 - - [27/Feb/2014 16:50:36] POST /v1/4ef47f119bc04d6dae054a5035359641/volumes HTTP/1.1 401 191 0.299349 http://logs.openstack.org/35/75535/1/gate/gate-grenade- dsvm/3c8e07e/logs/new/screen-c-api.txt.gz?#_2014-02-27_16_50_36_158 logstash query: message:CertificateConfigError: Unable to load certificate. Ensure your system is configured properly. AND NOT filename:logs/screen-n-api.txt To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285833/+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 1285478] Re: Enforce alphabetical ordering in requirements file
This is pissing me off too. ** No longer affects: ceilometer -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285478 Title: Enforce alphabetical ordering in requirements file Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Identity (Keystone): New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in Tempest: In Progress Status in Trove - Database as a Service: New Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285478/+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 1285845] [NEW] NSX: Updated security profile name is not reflected in NSX-Manager
Public bug reported: Steps to Performed: 1. In Openstack Horizon, Create one security group and add some ingress, egress rules. 2. This security profile is correctly reflected in NSX-Manager with correct name and UUID. 2. Now change the name of this security profile through openstack horizon. Observed Behavior: == 1. Changed security profile's name is not reflected in NSX-Manager. In Manager old name is still exist. 2. Changed name is reflected correctly in neutron security-group-list .But in NSX-manager is not reflected. 3. Functionality of this security profile is working correctly only newly changed name is not reflected on NSX-Manager. ** Affects: neutron Importance: Undecided Assignee: Armando Migliaccio (armando-migliaccio) Status: New ** Tags: havana-backport-potential nicira ** Changed in: neutron Assignee: (unassigned) = Armando Migliaccio (armando-migliaccio) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285845 Title: NSX: Updated security profile name is not reflected in NSX-Manager Status in OpenStack Neutron (virtual network service): New Bug description: Steps to Performed: 1. In Openstack Horizon, Create one security group and add some ingress, egress rules. 2. This security profile is correctly reflected in NSX-Manager with correct name and UUID. 2. Now change the name of this security profile through openstack horizon. Observed Behavior: == 1. Changed security profile's name is not reflected in NSX-Manager. In Manager old name is still exist. 2. Changed name is reflected correctly in neutron security-group-list .But in NSX-manager is not reflected. 3. Functionality of this security profile is working correctly only newly changed name is not reflected on NSX-Manager. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1285845/+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 1285871] [NEW] Attempt to call strftime on a str fails revocation_list
Public bug reported: This causes heat authenticated operations to fail for me locally 2014-02-28 10:25:10.084 ERROR keystone.common.wsgi [-] 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/common/wsgi.py, line 211, in __call__ 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi result = method(context, **params) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/openstack/common/versionutils.py, line 102, in wrapped 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return func(*args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/common/controller.py, line 131, in inner 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return f(self, context, *args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/token/controllers.py, line 423, in revocation_list 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi t['expires'] = timeutils.isotime(expires) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/openstack/common/timeutils.py, line 38, in isotime 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi st = at.strftime(_ISO8601_TIME_FORMAT 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi AttributeError: 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Possibly the six.text_type check should be six.string_types, but actually that conditional should really be checking for isinstance datetime.datetime explicitly, since that is what timeutils.isotime is assuming. ** Affects: keystone Importance: Undecided Assignee: Steve Baker (steve-stevebaker) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1285871 Title: Attempt to call strftime on a str fails revocation_list Status in OpenStack Identity (Keystone): In Progress Bug description: This causes heat authenticated operations to fail for me locally 2014-02-28 10:25:10.084 ERROR keystone.common.wsgi [-] 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/common/wsgi.py, line 211, in __call__ 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi result = method(context, **params) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/openstack/common/versionutils.py, line 102, in wrapped 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return func(*args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/common/controller.py, line 131, in inner 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return f(self, context, *args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/token/controllers.py, line 423, in revocation_list 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi t['expires'] = timeutils.isotime(expires) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File /home/steveb/dev/localstack/keystone/keystone/openstack/common/timeutils.py, line 38, in isotime 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi st = at.strftime(_ISO8601_TIME_FORMAT 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi AttributeError: 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Possibly the six.text_type check should be six.string_types, but actually that conditional should really be checking for isinstance datetime.datetime explicitly, since that is what timeutils.isotime is assuming. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1285871/+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 1285880] [NEW] force_config_drive should be based on image property
Public bug reported: Currently there is a force_config_drive config item for each compute node. A VM migrated from host w/ force_config_drive to a host w/o it will lost the config_drive, this is not so good. Currently it's ok because most of the config drive information is only used at launch time. According to the comments , it's be better to be based on image property. One thing need consider is rebuild. A image is changed when rebuilding, and I think if new image has no property for config drive, there should be no config drive for it. Thus we have to distinguish between the config_drive requirement from user and from image property. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1285880 Title: force_config_drive should be based on image property Status in OpenStack Compute (Nova): New Bug description: Currently there is a force_config_drive config item for each compute node. A VM migrated from host w/ force_config_drive to a host w/o it will lost the config_drive, this is not so good. Currently it's ok because most of the config drive information is only used at launch time. According to the comments , it's be better to be based on image property. One thing need consider is rebuild. A image is changed when rebuilding, and I think if new image has no property for config drive, there should be no config drive for it. Thus we have to distinguish between the config_drive requirement from user and from image property. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1285880/+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 1285893] [NEW] ovs_neutron_agent is missing test coverage
Public bug reported: neutron/tests/unit/openvswitch/test_ovs_neutron_agent.py is missing test coverage ** Affects: neutron Importance: Medium Status: Triaged ** Tags: havana-backport-potential ovs -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285893 Title: ovs_neutron_agent is missing test coverage Status in OpenStack Neutron (virtual network service): Triaged Bug description: neutron/tests/unit/openvswitch/test_ovs_neutron_agent.py is missing test coverage To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1285893/+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 1285885] [NEW] update_port passes device_id=None but neutron expects ''
Public bug reported: 2014-02-27 14:08:23.013 ERROR nova.network.neutronv2.api [req-598b0d2f-e4e9-40eb-a9d4-027975d08b39 demo demo] Failed to delete neutron port 153f472b-f662-497b-bc7c-3cc362157ab1 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api Traceback (most recent call last): 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/nova/nova/network/neutronv2/api.py, line 420, in deallocate_for_instance 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api neutron.update_port(port, port_req_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 111, in with_params 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api ret = self.function(instance, *args, **kwargs) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 321, in update_port 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api return self.put(self.port_path % (port), body=body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1245, in put 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api headers=headers, params=params) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1221, in retry_request 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api headers=headers, params=params) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1164, in do_request 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api self._handle_fault_response(status_code, replybody) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1134, in _handle_fault_response 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api exception_handler_v20(status_code, des_error_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 84, in exception_handler_v20 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api message=error_dict) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api NeutronClientException: Invalid input for device_id. Reason: 'None' is not a valid string. 2014-02-27 14:08:23.011 ERROR neutron.api.v2.resource [req-3f133c17-198f-412d-b57e-66bbf0fcfbcb neutron abd2b56aa998417ba5af609a680a138d] update failed 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource Traceback (most recent call last): 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/resource.py, line 84, in resource 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource result = method(request=request, **args) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/base.py, line 466, in update 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource allow_bulk=self._allow_bulk) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/base.py, line 600, in prepare_request_body 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource raise webob.exc.HTTPBadRequest(msg) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource HTTPBadRequest: Invalid input for device_id. Reason: 'None' is not a valid string. 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1285885 Title: update_port passes device_id=None but neutron expects '' Status in OpenStack Compute (Nova): New Bug description: 2014-02-27 14:08:23.013 ERROR nova.network.neutronv2.api [req-598b0d2f-e4e9-40eb-a9d4-027975d08b39 demo demo] Failed to delete neutron port 153f472b-f662-497b-bc7c-3cc362157ab1 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api Traceback (most recent call last): 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/nova/nova/network/neutronv2/api.py, line 420, in deallocate_for_instance 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api neutron.update_port(port, port_req_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 111, in with_params 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api ret = self.function(instance, *args, **kwargs) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 321, in update_port 2014-02-27 14:08:23.013 TRACE
[Yahoo-eng-team] [Bug 1285886] [NEW] update_port passes device_id=None but neutron expects ''
Public bug reported: 2014-02-27 14:08:23.013 ERROR nova.network.neutronv2.api [req-598b0d2f-e4e9-40eb-a9d4-027975d08b39 demo demo] Failed to delete neutron port 153f472b-f662-497b-bc7c-3cc362157ab1 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api Traceback (most recent call last): 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/nova/nova/network/neutronv2/api.py, line 420, in deallocate_for_instance 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api neutron.update_port(port, port_req_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 111, in with_params 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api ret = self.function(instance, *args, **kwargs) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 321, in update_port 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api return self.put(self.port_path % (port), body=body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1245, in put 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api headers=headers, params=params) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1221, in retry_request 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api headers=headers, params=params) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1164, in do_request 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api self._handle_fault_response(status_code, replybody) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 1134, in _handle_fault_response 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api exception_handler_v20(status_code, des_error_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 84, in exception_handler_v20 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api message=error_dict) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api NeutronClientException: Invalid input for device_id. Reason: 'None' is not a valid string. 2014-02-27 14:08:23.011 ERROR neutron.api.v2.resource [req-3f133c17-198f-412d-b57e-66bbf0fcfbcb neutron abd2b56aa998417ba5af609a680a138d] update failed 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource Traceback (most recent call last): 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/resource.py, line 84, in resource 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource result = method(request=request, **args) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/base.py, line 466, in update 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource allow_bulk=self._allow_bulk) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource File /opt/stack/neutron/neutron/api/v2/base.py, line 600, in prepare_request_body 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource raise webob.exc.HTTPBadRequest(msg) 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource HTTPBadRequest: Invalid input for device_id. Reason: 'None' is not a valid string. 2014-02-27 14:08:23.011 TRACE neutron.api.v2.resource ** Affects: nova Importance: Low Assignee: Aaron Rosen (arosen) Status: New ** Tags: network ** Changed in: nova Assignee: (unassigned) = Aaron Rosen (arosen) ** Changed in: nova Importance: Undecided = Low ** Tags added: network -- 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/1285886 Title: update_port passes device_id=None but neutron expects '' Status in OpenStack Compute (Nova): New Bug description: 2014-02-27 14:08:23.013 ERROR nova.network.neutronv2.api [req-598b0d2f-e4e9-40eb-a9d4-027975d08b39 demo demo] Failed to delete neutron port 153f472b-f662-497b-bc7c-3cc362157ab1 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api Traceback (most recent call last): 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/nova/nova/network/neutronv2/api.py, line 420, in deallocate_for_instance 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api neutron.update_port(port, port_req_body) 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api File /opt/stack/python-neutronclient/neutronclient/v2_0/client.py, line 111, in with_params 2014-02-27 14:08:23.013 TRACE nova.network.neutronv2.api ret = self.function(instance, *args, **kwargs)
[Yahoo-eng-team] [Bug 1285908] [NEW] IOError: [Errno 2] No such file or directory: '/opt/stack/data/nova/instances/UUID/libvirt.xml'
Public bug reported: 2014-02-27 22:17:30.887 26111 ERROR oslo.messaging.rpc.dispatcher [-] Exception during message handling: [Errno 2] No such file or directory: '/opt/stack/data/nova/instances/32ce67c4-8444-4f3a-8fda-58c8e303efdc/libvirt.xml' 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py, line 133, in _dispatch_and_reply 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py, line 176, in _dispatch 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py, line 122, in _do_dispatch 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 88, in wrapped 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher payload) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 68, in __exit__ 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 71, in wrapped 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 243, in decorated_function 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher pass 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 68, in __exit__ 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 229, in decorated_function 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 294, in decorated_function 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher function(self, context, *args, **kwargs) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 271, in decorated_function 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher e, sys.exc_info()) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 68, in __exit__ 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 258, in decorated_function 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 2076, in start_instance 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher self._power_on(context, instance) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 2064, in _power_on 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher block_device_info) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2093, in power_on 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher self._hard_reboot(context, instance, network_info, block_device_info) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2045, in _hard_reboot 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher write_to_disk=True) 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 3363, in to_xml 2014-02-27 22:17:30.887 26111 TRACE oslo.messaging.rpc.dispatcher libvirt_utils.write_to_file(xml_path, xml) 2014-02-27
[Yahoo-eng-team] [Bug 1283803] Re: keystone listens locally on admin port
Reviewed: https://review.openstack.org/75954 Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=041fa712472d887550a540dd50ade546f847c6b4 Submitter: Jenkins Branch:master commit 041fa712472d887550a540dd50ade546f847c6b4 Author: David Kranz dkr...@redhat.com Date: Mon Feb 24 13:30:59 2014 -0500 Make admin_bind_host configurable The use case is running devstack inside an OpenStack vm and running tempest from some other machine. To make the catalog export urls that can be accessed from off the devstack machine, you need to set KEYSTONE_SERVICE_HOST to an external IP. But devstack uses that address in its setup of keystone in addition to exporting in the catalog. Because OpenStack has an issue where a vm cannot access itself through its own floating ip, devstack fails. There is no way to have this use case by providing an ip address. The workaround is to use the hostname of the devstack machine. That worked until recently when a change was made to set admin_bind_host to the value of KEYSTONE_SERVICE_HOST. The result is that port 35357 is only opened locally. This change allows the devstack user to restore the original behavior allowing this use case. Change-Id: I97b938b305b7dd878397e7e64462650064e59cd2 Closes-Bug: #1283803 ** Changed in: devstack Status: In Progress = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1283803 Title: keystone listens locally on admin port Status in devstack - openstack dev environments: Fix Released Status in OpenStack Identity (Keystone): Invalid Bug description: I installed a vanilla devstack except for setting SERVICE_HOST in localrc so I could run tempest from another machine. Tempest fails trying to connect to adminURL and it seems to be because port 35357 is only open locally. The conf file comment says: # The base admin endpoint URL for keystone that are advertised # to clients (NOTE: this does NOT affect how keystone listens # for connections) (string value) #admin_endpoint=http://localhost:%(admin_port)s/ But this from netstat. I would expect 35357 to be the same as the others. It is also possible this is a devstack issue but I'm not sure so starting here. Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 *:iscsi-target *:* LISTEN tcp0 0 *:40956 *:* LISTEN tcp0 0 localhost:35357 *:* LISTEN tcp0 0 *:6080 *:* LISTEN tcp0 0 *:6081 *:* LISTEN tcp0 0 *: *:* LISTEN tcp0 0 *:8773 *:* LISTEN tcp0 0 *:8774 *:* LISTEN tcp0 0 *:8775 *:* LISTEN tcp0 0 *:9191 *:* LISTEN tcp0 0 *:8776 *:* LISTEN tcp0 0 *:5000 *:* LISTEN ... elided ... And catalog:+-+---+ | Property | Value | +-+---+ | adminURL | http://dkranz-devstack:35357/v2.0 | | id | 39932d3dcf4340a98727294ed5ec71b8 | | internalURL | http://dkranz-devstack:5000/v2.0 | | publicURL | http://dkranz-devstack:5000/v2.0 | |region | RegionOne | +-+---+ To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1283803/+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 1285922] [NEW] Add quota check to Extend Volume dialog
Public bug reported: In Extend Volume dialog if the size provided is larger than available quota the extend action takes place and then an error is displayed. It would be better to run the size vs. quota check first before triggering the action. Steps to reproduce: 1. Go to Project Volumes 2. Create an empty volume of 1 GB size 3. Extend the volume and for the new size type in a number that's beyond the available quota (1200) 4. You'll notice the modal is closed and an error message is shown saying Error: Unable to extend volume with no indication of what went wrong. Suggestion is to show a proper error message on the modal. ** Affects: horizon Importance: Undecided Status: New ** Tags: extend horizon volume -- 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/1285922 Title: Add quota check to Extend Volume dialog Status in OpenStack Dashboard (Horizon): New Bug description: In Extend Volume dialog if the size provided is larger than available quota the extend action takes place and then an error is displayed. It would be better to run the size vs. quota check first before triggering the action. Steps to reproduce: 1. Go to Project Volumes 2. Create an empty volume of 1 GB size 3. Extend the volume and for the new size type in a number that's beyond the available quota (1200) 4. You'll notice the modal is closed and an error message is shown saying Error: Unable to extend volume with no indication of what went wrong. Suggestion is to show a proper error message on the modal. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1285922/+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 1282514] Re: python 3 only has __self__, the im_self should be replace by __self_
Fix proposed to branch: master Review: https://review.openstack.org/77036 ** Changed in: nova Status: Invalid = In Progress -- 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/1282514 Title: python 3 only has __self__, the im_self should be replace by __self_ Status in Cinder: In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Status in Tuskar: Fix Committed Bug description: for code compatible with Python 3, we should use the __self__ instead of im_self. for example : cinder/volume/flows/common.py def make_pretty_name(method): Makes a pretty name for a function/method. meth_pieces = [method.__name__] # If its an instance method attempt to tack on the class name if hasattr(method, 'im_self') and method.im_self is not None: try: meth_pieces.insert(0, method.im_self.__class__.__name__) except AttributeError: pass return ..join(meth_pieces) For reference here(thanks Alex for adding this): Changed in version 2.6: For Python 3 forward-compatibility, im_func is also available as __func__, and im_self as __self__. http://docs.python.org/2/reference/datamodel.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1282514/+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 1284677] Re: Python 3: do not use 'unicode()'
** Also affects: tuskar Importance: Undecided Status: New ** Changed in: tuskar Assignee: (unassigned) = Fengqian (fengqian-gao) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1284677 Title: Python 3: do not use 'unicode()' Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Python client library for Glance: In Progress Status in Tuskar: New Bug description: The unicode() function is Python2-specific, we should use six.text_type() instead. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1284677/+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 1285962] [NEW] Configurable values is not printed in the ovs-neutron-agent log file
Public bug reported: When the neutron-server starts up, it prints out the configurable values in the q-svc log. This values is useful in debugging problems. Such output is not in the ovs-neutron-agent's log file. Configurable value output in screen-q-svc.log: $ cd /opt/stack/neutron python /usr/local/bin/ ^Mneutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutro ^Mn/plugins/ml2/ml2_conf.ini echo $! /opt/stack/status/stack/q-svc.pid; fg || e ^Mcho q-svc failed to start | tee /opt/stack/status/stack/q-svc.failure [1] 29287 cd /opt/stack/neutron python /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini 2014-02-27 13:19:20.245 29288 INFO neutron.common.config [-] Logging enabled! 2014-02-27 13:19:20.245 29288 ERROR neutron.common.legacy [-] Skipping unknown group key: firewall_driver 2014-02-27 13:19:20.245 29288 DEBUG neutron.service [-] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1900 2014-02-27 13:19:20.245 29288 DEBUG neutron.service [-] Configuration options gathered from: log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1901 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] command line args: ['--config-file', '/etc/neutron/neutron.conf', '--config-file', '/etc/neutron/plugins/ml2/ml2_conf.ini'] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1902 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] config files: ['/etc/neutron/neutron.conf', '/etc/neutron/plugins/ml2/ml2_conf.ini'] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1903 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1904 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] allow_bulk = True log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1913 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] allow_overlapping_ips = True log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1913 . . . 2014-02-27 13:19:20.256 29288 DEBUG neutron.service [-] database.min_pool_size = 1 log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1921 2014-02-27 13:19:20.256 29288 DEBUG neutron.service [-] database.pool_timeout = 10 log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1921 2014-02-27 13:19:20.256 29288 DEBUG neutron.service [-] database.retry_interval = 10 log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1921 2014-02-27 13:19:20.256 29288 DEBUG neutron.service [-] database.slave_connection = log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1921 2014-02-27 13:19:20.257 29288 DEBUG neutron.service [-] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1923 2014-02-27 13:19:20.257 29288 INFO neutron.common.config [-] Config paste file: /etc/neutron/api-paste.ini ** Affects: neutron Importance: Undecided Assignee: Stephen Ma (stephen-ma) Status: New ** Description changed: When the neutron-server starts up, it prints out the configurable values in the q-svc log. This values is useful in debugging problems. Such output is not in the ovs-neutron-agent's log file. - a$ cd /opt/stack/neutron python /usr/local/bin/ ^Mneutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutro ^Mn/plugins/ml2/ml2_conf.ini echo $! /opt/stack/status/stack/q-svc.pid; fg || e ^Mcho q-svc failed to start | tee /opt/stack/status/stack/q-svc.failure + Configurable value output in screen-q-svc.log: + + $ cd /opt/stack/neutron python /usr/local/bin/ ^Mneutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutro ^Mn/plugins/ml2/ml2_conf.ini echo $! /opt/stack/status/stack/q-svc.pid; fg || e ^Mcho q-svc failed to start | tee /opt/stack/status/stack/q-svc.failure [1] 29287 cd /opt/stack/neutron python /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini 2014-02-27 13:19:20.245 29288 INFO neutron.common.config [-] Logging enabled! 2014-02-27 13:19:20.245 29288 ERROR neutron.common.legacy [-] Skipping unknown group key: firewall_driver 2014-02-27 13:19:20.245 29288 DEBUG neutron.service [-] log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1900 2014-02-27 13:19:20.245 29288 DEBUG neutron.service [-] Configuration options gathered from: log_opt_values /opt/stack/oslo.config/oslo/config/cfg.py:1901 2014-02-27 13:19:20.246 29288 DEBUG neutron.service [-] command line args: ['--config-file', '/etc/neutron/neutron.conf', '--config-file',
[Yahoo-eng-team] [Bug 1285478] Re: Enforce alphabetical ordering in requirements file
** Also affects: tuskar 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/1285478 Title: Enforce alphabetical ordering in requirements file Status in Cinder: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in Tempest: In Progress Status in Trove - Database as a Service: New Status in Tuskar: In Progress Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285478/+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 1241187] Re: keystone admin apache
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete = Expired -- 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/1241187 Title: keystone admin apache Status in OpenStack Dashboard (Horizon): Expired Bug description: I'm running openstack-dashboard-2013.2-0.12.rc1.el6.noarch from RDO on rhel 6.4. I have keystone running under apache with endpoints: /keystone/main/v2.0 /keystone/admin/v2.0 I have set in local_settings: OPENSTACK_HOST = vam.emsl.pnl.gov OPENSTACK_KEYSTONE_URL = https://%s/keystone/main/v2.0; % OPENSTACK_HOST The user section is working great. Logging into it as admin and showing the admin pages breaks. Looking at the logs, it is trying to talk to the wrong place: [Thu Oct 17 20:14:11 2013] [error] REQ: curl -i -X GET https://vam.emsl.pnl.gov/v2.0/tenants?limit=21 -H User-Agent: python-keystoneclient -H Forwarded: for=130.20.227.254;by=python-keystoneclient -H X-Auth-Token: XXX The endpoints in keystone look correct: | f342e89ec3524e22bc126ce29df7e655 | RegionOne | https://vam.emsl.pnl.gov/keystone/main/v2.0 | https://vam.emsl.pnl.gov/keystone/main/v2.0 | https://vam.emsl.pnl.gov/keystone/admin/v2.0 | 2a795982bdcd4215960d569f64300072 | To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1241187/+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 1244457] Re: ServiceCatalogException: Invalid service catalog service: compute
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete = Expired -- 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/1244457 Title: ServiceCatalogException: Invalid service catalog service: compute Status in OpenStack Dashboard (Horizon): Expired Bug description: On the following review - https://review.openstack.org/#/c/53712/ We failed the tempest tests on the dashboard scenario tests for the pg version of the job: 2013-10-24 21:26:00.445 | == 2013-10-24 21:26:00.445 | FAIL: tempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] 2013-10-24 21:26:00.445 | tempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] 2013-10-24 21:26:00.445 | -- 2013-10-24 21:26:00.446 | _StringException: Empty attachments: 2013-10-24 21:26:00.446 | pythonlogging:'' 2013-10-24 21:26:00.446 | stderr 2013-10-24 21:26:00.446 | stdout 2013-10-24 21:26:00.446 | 2013-10-24 21:26:00.446 | Traceback (most recent call last): 2013-10-24 21:26:00.446 | File tempest/scenario/test_dashboard_basic_ops.py, line 73, in test_basic_scenario 2013-10-24 21:26:00.447 | self.user_login() 2013-10-24 21:26:00.447 | File tempest/scenario/test_dashboard_basic_ops.py, line 64, in user_login 2013-10-24 21:26:00.447 | self.opener.open(req, urllib.urlencode(params)) 2013-10-24 21:26:00.447 | File /usr/lib/python2.7/urllib2.py, line 406, in open 2013-10-24 21:26:00.447 | response = meth(req, response) 2013-10-24 21:26:00.447 | File /usr/lib/python2.7/urllib2.py, line 519, in http_response 2013-10-24 21:26:00.447 | 'http', request, response, code, msg, hdrs) 2013-10-24 21:26:00.448 | File /usr/lib/python2.7/urllib2.py, line 438, in error 2013-10-24 21:26:00.448 | result = self._call_chain(*args) 2013-10-24 21:26:00.448 | File /usr/lib/python2.7/urllib2.py, line 378, in _call_chain 2013-10-24 21:26:00.448 | result = func(*args) 2013-10-24 21:26:00.448 | File /usr/lib/python2.7/urllib2.py, line 625, in http_error_302 2013-10-24 21:26:00.448 | return self.parent.open(new, timeout=req.timeout) 2013-10-24 21:26:00.448 | File /usr/lib/python2.7/urllib2.py, line 406, in open 2013-10-24 21:26:00.449 | response = meth(req, response) 2013-10-24 21:26:00.449 | File /usr/lib/python2.7/urllib2.py, line 519, in http_response 2013-10-24 21:26:00.449 | 'http', request, response, code, msg, hdrs) 2013-10-24 21:26:00.449 | File /usr/lib/python2.7/urllib2.py, line 438, in error 2013-10-24 21:26:00.449 | result = self._call_chain(*args) 2013-10-24 21:26:00.449 | File /usr/lib/python2.7/urllib2.py, line 378, in _call_chain 2013-10-24 21:26:00.449 | result = func(*args) 2013-10-24 21:26:00.450 | File /usr/lib/python2.7/urllib2.py, line 625, in http_error_302 2013-10-24 21:26:00.450 | return self.parent.open(new, timeout=req.timeout) 2013-10-24 21:26:00.450 | File /usr/lib/python2.7/urllib2.py, line 406, in open 2013-10-24 21:26:00.450 | response = meth(req, response) 2013-10-24 21:26:00.450 | File /usr/lib/python2.7/urllib2.py, line 519, in http_response 2013-10-24 21:26:00.450 | 'http', request, response, code, msg, hdrs) 2013-10-24 21:26:00.450 | File /usr/lib/python2.7/urllib2.py, line 444, in error 2013-10-24 21:26:00.451 | return self._call_chain(*args) 2013-10-24 21:26:00.451 | File /usr/lib/python2.7/urllib2.py, line 378, in _call_chain 2013-10-24 21:26:00.451 | result = func(*args) 2013-10-24 21:26:00.451 | File /usr/lib/python2.7/urllib2.py, line 527, in http_error_default 2013-10-24 21:26:00.451 | raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) 2013-10-24 21:26:00.451 | HTTPError: HTTP Error 500: INTERNAL SERVER ERROR The horizon logs have the following error info: [Thu Oct 24 21:18:43 2013] [error] Internal Server Error: /project/ [Thu Oct 24 21:18:43 2013] [error] Traceback (most recent call last): [Thu Oct 24 21:18:43 2013] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 115, in get_response [Thu Oct 24 21:18:43 2013] [error] response = callback(request, *callback_args, **callback_kwargs) [Thu Oct 24 21:18:43 2013] [error] File /opt/stack/new/horizon/openstack_dashboard/wsgi/../../horizon/decorators.py, line 38, in dec [Thu Oct 24 21:18:43 2013] [error] return view_func(request, *args, **kwargs) [Thu Oct 24 21:18:43 2013] [error] File /opt/stack/new/horizon/openstack_dashboard/wsgi/../../horizon/decorators.py, line 54, in dec
[Yahoo-eng-team] [Bug 1285478] Re: Enforce alphabetical ordering in requirements file
** Also affects: marconi Importance: Undecided Status: New ** Changed in: marconi Status: New = In Progress ** Changed in: marconi Assignee: (unassigned) = Fengqian (fengqian-gao) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285478 Title: Enforce alphabetical ordering in requirements file Status in Cinder: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Message Queuing Service (Marconi): In Progress Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in Tempest: In Progress Status in Trove - Database as a Service: In Progress Status in Tuskar: In Progress Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285478/+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 1285993] [NEW] neutron-server crashes when running on an empty database
Public bug reported: operation: $ mysql create database neutron_ml2 character set utf8; exit $ neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini error: 2014-02-28 15:02:46.550 TRACE neutron ProgrammingError: (ProgrammingError) (1146, Table 'neutron_ml2.ml2_vlan_allocations' doesn't exist) 'SELECT ml2_vlan_allocations.physical_network AS ml2_vlan_allocations_physical_network, ml2_vlan_allocations.vlan_id AS ml2_vlan_allocations_vlan_id, ml2_vlan_allocations.allocated AS ml2_vlan_allocations_allocated \nFROM ml2_vlan_allocations FOR UPDATE' () investigation: This problem introduced by https://review.openstack.org/#/c/74896/ . Not that this problem does not occur if nuetron-db-manage is run before running neutron-server since ml2_vlan_allocations table is created by neutron-db-manage. I did skip running neutron-db-manage usually and it was no problem. Is it prohibited now ? ** 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/1285993 Title: neutron-server crashes when running on an empty database Status in OpenStack Neutron (virtual network service): New Bug description: operation: $ mysql create database neutron_ml2 character set utf8; exit $ neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini error: 2014-02-28 15:02:46.550 TRACE neutron ProgrammingError: (ProgrammingError) (1146, Table 'neutron_ml2.ml2_vlan_allocations' doesn't exist) 'SELECT ml2_vlan_allocations.physical_network AS ml2_vlan_allocations_physical_network, ml2_vlan_allocations.vlan_id AS ml2_vlan_allocations_vlan_id, ml2_vlan_allocations.allocated AS ml2_vlan_allocations_allocated \nFROM ml2_vlan_allocations FOR UPDATE' () investigation: This problem introduced by https://review.openstack.org/#/c/74896/ . Not that this problem does not occur if nuetron-db-manage is run before running neutron-server since ml2_vlan_allocations table is created by neutron-db-manage. I did skip running neutron-db-manage usually and it was no problem. Is it prohibited now ? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1285993/+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 1285999] [NEW] neutron's extension loader behaviour is not consistent
Public bug reported: We saw this in our startup logs: 2014-02-27 16:37:07,702 (neutron.api.extensions): INFO extensions add_extension Loaded extension: nvp-qos 2014-02-27 16:37:07,702 (neutron.api.extensions): INFO extensions _load_all_extensions_from_path Loading extension file: nvp_networkgw.py 2014-02-27 16:37:07,703 (neutron.api.extensions): DEBUG extensions _check_extension Ext name: Neutron-NVP Network Gateway 2014-02-27 16:37:07,703 (neutron.api.extensions): DEBUG extensions _check_extension Ext alias: network-gateway 2014-02-27 16:37:07,704 (neutron.api.extensions): DEBUG extensions _check_extension Ext description: Connects Neutron networks with external networks at layer 2 (deprecated). 2014-02-27 16:37:07,704 (neutron.api.extensions): DEBUG extensions _check_extension Ext namespace: http://docs.openstack.org/ext/neutron/network-gateway/api/v1.0 2014-02-27 16:37:07,705 (neutron.api.extensions): DEBUG extensions _check_extension Ext updated: 2014-01-01T00:00:00-00:00 2014-02-27 16:37:07,705 (neutron.api.extensions): INFO extensions add_extension Loaded extension: network-gateway 2014-02-27 16:37:07,705 (neutron.api.extensions): WARNING extensions _load_all_extensions_from_path Extension file nvp_networkgw.py wasn't loaded due to Found duplicate extension: network-gateway There are two neutron servers load balanced, the other server did not show this. While running tempest against them, it was failing because both servers advertised different names for their network-gateway extension. Restarting neutron on the bad server did not show this behavior. ** 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/1285999 Title: neutron's extension loader behaviour is not consistent Status in OpenStack Neutron (virtual network service): New Bug description: We saw this in our startup logs: 2014-02-27 16:37:07,702 (neutron.api.extensions): INFO extensions add_extension Loaded extension: nvp-qos 2014-02-27 16:37:07,702 (neutron.api.extensions): INFO extensions _load_all_extensions_from_path Loading extension file: nvp_networkgw.py 2014-02-27 16:37:07,703 (neutron.api.extensions): DEBUG extensions _check_extension Ext name: Neutron-NVP Network Gateway 2014-02-27 16:37:07,703 (neutron.api.extensions): DEBUG extensions _check_extension Ext alias: network-gateway 2014-02-27 16:37:07,704 (neutron.api.extensions): DEBUG extensions _check_extension Ext description: Connects Neutron networks with external networks at layer 2 (deprecated). 2014-02-27 16:37:07,704 (neutron.api.extensions): DEBUG extensions _check_extension Ext namespace: http://docs.openstack.org/ext/neutron/network-gateway/api/v1.0 2014-02-27 16:37:07,705 (neutron.api.extensions): DEBUG extensions _check_extension Ext updated: 2014-01-01T00:00:00-00:00 2014-02-27 16:37:07,705 (neutron.api.extensions): INFO extensions add_extension Loaded extension: network-gateway 2014-02-27 16:37:07,705 (neutron.api.extensions): WARNING extensions _load_all_extensions_from_path Extension file nvp_networkgw.py wasn't loaded due to Found duplicate extension: network-gateway There are two neutron servers load balanced, the other server did not show this. While running tempest against them, it was failing because both servers advertised different names for their network-gateway extension. Restarting neutron on the bad server did not show this behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1285999/+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 1285478] Re: Enforce alphabetical ordering in requirements file
** Also affects: storyboard Importance: Undecided Status: New ** Changed in: storyboard Status: New = In Progress ** Changed in: storyboard Assignee: (unassigned) = Fengqian (fengqian-gao) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1285478 Title: Enforce alphabetical ordering in requirements file Status in Cinder: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic (Bare Metal Provisioning): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Message Queuing Service (Marconi): In Progress Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Python client library for Cinder: New Status in Python client library for Glance: New Status in Python client library for heat: New Status in Python client library for Ironic: In Progress Status in Python client library for Neutron: New Status in Python client library for Nova: In Progress Status in Trove client binding: New Status in OpenStack contribution dashboard: New Status in Storyboard database creator: In Progress Status in Tempest: In Progress Status in Trove - Database as a Service: In Progress Status in Tuskar: In Progress Bug description: Sorting requirement files in alphabetical order makes code more readable, and can check whether specific library in the requirement files easily. Hacking donesn't check *.txt files. We had enforced this check in oslo-incubator https://review.openstack.org/#/c/66090/. This bug is used to track syncing the check gating. How to sync this to other projects: 1. Copy tools/requirements_style_check.sh to project/tools. 2. run tools/requirements_style_check.sh requirements.txt test- requirements.txt 3. fix the violations To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1285478/+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 1286006] [NEW] Static injection pure IPv6 address will throw exception in vmware driver
Public bug reported: With use vmware center dirver in nova, and set flat_injected = True to static inject pure IPv6, from code, this function still not be implemented, but it shoud not throw excepption, when the network_info is one pure IPv6 information, it will impact nova compute service work. ** Affects: nova Importance: Undecided Assignee: Dazhao Yu (dzyu) Status: New ** Tags: vmware ** Changed in: nova Assignee: (unassigned) = Dazhao Yu (dzyu) -- 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/1286006 Title: Static injection pure IPv6 address will throw exception in vmware driver Status in OpenStack Compute (Nova): New Bug description: With use vmware center dirver in nova, and set flat_injected = True to static inject pure IPv6, from code, this function still not be implemented, but it shoud not throw excepption, when the network_info is one pure IPv6 information, it will impact nova compute service work. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1286006/+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
