[Yahoo-eng-team] [Bug 1655833] [NEW] The error response for placement API doesn't work with i18n
Public bug reported: In most of placement API code, we just put the exception into the error message like this https://github.com/openstack/nova/blob/d57ce1dda839865c8060458760fa27dbbd7e2aee/nova/api/openstack/placement/handlers/resource_class.py#L108 This is equal to str(exc). This won't works for i18n. We can use "exc.format_message()" ** Affects: nova Importance: Undecided Status: New ** Tags: placement ** Tags added: placement -- 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/1655833 Title: The error response for placement API doesn't work with i18n Status in OpenStack Compute (nova): New Bug description: In most of placement API code, we just put the exception into the error message like this https://github.com/openstack/nova/blob/d57ce1dda839865c8060458760fa27dbbd7e2aee/nova/api/openstack/placement/handlers/resource_class.py#L108 This is equal to str(exc). This won't works for i18n. We can use "exc.format_message()" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655833/+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 1600418] Re: Flavor name edit should trim for white spaces and compare with other flavor names
Reviewed: https://review.openstack.org/403687 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=23c482b941b53243b9f57c5707d266870c3c2225 Submitter: Jenkins Branch:master commit 23c482b941b53243b9f57c5707d266870c3c2225 Author: Yakup Adakli Date: Mon Nov 28 15:28:44 2016 +0300 Strip whitespace added to flavor name in create and update flavor. Change-Id: I633a4124615ca0c6cfe6b103e117e3ebd6d79241 Closes-Bug: #1600418 ** Changed in: horizon Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1600418 Title: Flavor name edit should trim for white spaces and compare with other flavor names Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When editing the flavor name from horizon 1. Enter new flavor name which is same as one of the existing flavor name 2. Make sure that you have entered leading and trailing spaces Try saving this flavor and it fails with error. we should ideally strip the flavor name before making any comparison. As a specific example 1. Create flavor with name test1 2. Create flavor with name test2 3. Edit flavor test2 4. When editing try giving name "test1"(new name same as one of the existing flavor and leading and trailing spaces in the new name) 5. Save the flavor 6. we get an error that 'Unable to modify test1'. Now we were modifying test2 and not test1. Error should ideally say that the flavor with name 'test1' already exists(as the case is if we try the same from CLI) One more unexpected behavior that happens is that 'test2' in above case is removed from the flavor listing page in UI To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1600418/+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 1311582] Re: resource usage for storage components shows no results
Ceilometer isn't part of Horizon any longer. ** Changed in: horizon Status: New => Invalid ** Changed in: horizon Importance: Undecided => Medium -- 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/1311582 Title: resource usage for storage components shows no results Status in OpenStack Dashboard (Horizon): Invalid Bug description: when I try to view storage resources in horizon's "resource usage" tab we get no data available message. looking at horizon log I see that we are getting an error but can't find anything in ceilometer to suggest why we fail to show the info. HTTP/0.9 200 Error response Error response Error code 400. Message: Bad request syntax ('GET /v2/meters/image.update /statistics?q.field=project_id&q.field=timestamp&q.field=timestamp&q.op=eq&q.op=ge&q.op=le&q.type=&q.type=&q.type=&q.value=18b1ac6dfd3f4235a420d136662c7062&q.value=2014-04-16+10%3A10%3A11.121506&q.value=2014-04-23+10%3A10%3A11.121522&period=1512 HTTP/1.1'). Error code explanation: 400 = Bad request syntax or unsupported method. 2014-04-23 10:10:11,267 2351 DEBUG ceilometerclient.common.http HTTP/0.9 200 Error response Error response Error code 400. Message: Bad request syntax ('GET /v2/meters/image.update /statistics?q.field=project_id&q.field=timestamp&q.field=timestamp&q.op=eq&q.op=ge&q.op=le&q.type=&q.type=&q.type=&q.value=c3178ebef2c24d1b9a045bd67483a83c&q.value=2014-04-16+10%3A10%3A11.121506&q.value=2014-04-23+10%3A10%3A11.121522&period=1512 HTTP/1.1'). Error code explanation: 400 = Bad request syntax or unsupported method. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1311582/+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 1655810] [NEW] firewall-policy-insert-rule iptables rule does not take effect
Public bug reported: when execute neutron firewall-policy-insert-rule ** command,The configuration takes effect,but the iptables rule doesn't takes effect on the computer node. ** 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/1655810 Title: firewall-policy-insert-rule iptables rule does not take effect Status in neutron: New Bug description: when execute neutron firewall-policy-insert-rule ** command,The configuration takes effect,but the iptables rule doesn't takes effect on the computer node. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1655810/+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 1655785] [NEW] Use the session loader in keystoneauth1 for designate
Public bug reported: https://review.openstack.org/416048 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit b38f1cb1f737dede90f3df74f3515d63c357fa30 Author: Gyorgy Szombathelyi Date: Mon Dec 19 13:58:10 2016 +0100 Use the session loader in keystoneauth1 for designate Using the session loader has the benefit of compatibility with settings in other sections (like keystone_authtoken), and the ability to use client certs and setting the timeout. This changes the designate.ca_cert setting to designate.cafile, but the former is added as a deprecated option, so existing config files will work. DocImpact ca_cert in [designate] is deprecated, use cafile instead. Change-Id: I9f2173b02af5c3929a96ef8c773d587e9b673d62 ** Affects: neutron Importance: Undecided Status: New ** Tags: doc neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1655785 Title: Use the session loader in keystoneauth1 for designate Status in neutron: New Bug description: https://review.openstack.org/416048 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit b38f1cb1f737dede90f3df74f3515d63c357fa30 Author: Gyorgy Szombathelyi Date: Mon Dec 19 13:58:10 2016 +0100 Use the session loader in keystoneauth1 for designate Using the session loader has the benefit of compatibility with settings in other sections (like keystone_authtoken), and the ability to use client certs and setting the timeout. This changes the designate.ca_cert setting to designate.cafile, but the former is added as a deprecated option, so existing config files will work. DocImpact ca_cert in [designate] is deprecated, use cafile instead. Change-Id: I9f2173b02af5c3929a96ef8c773d587e9b673d62 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1655785/+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 1649446] Re: Non-Admin Access to Revocation Events
Consensus seems to be that this was intentional behavior, but worth changing (as evidenced by a subsequent fix to master). Given that and the lack of stable branch backports, I'm going to treat this as a security hardening opportunity. If there is fierce disagreement favoring backports and an official advisory, we can revisit the classification at that time. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1649446 Title: Non-Admin Access to Revocation Events Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: With the default Keystone policy any authed user can list all revocation events for the cluster: https://github.com/openstack/keystone/blob/master/etc/policy.json#L179 This can be done by directly calling the API as such: curl -g -i -X GET http://localhost/identity/v3/OS-REVOKE/events -H "Accept: application/json" -H "X-Auth-Token: " and this will provide you with a normal revocation event list (see attachment). This will allow a user to over time collect a list of user_ids and project_ids. The project_ids aren't particularly useful, but the user_ids can be used to lock people of of their accounts. Or if rate limiting is not setup (a bad idea), or somehow bypassed, would allow someone to brute force access to those ids. Knowing the ids is no worse than knowing the usernames, but as a non- admin you shouldn't have access to such a list anyway. It is also worth noting that OpenStack policy files are rife with these blank policy rules, not just Keystone. Some are safe and intended to be accessible by any authed user, others are checked at the code layer, but there may be other rules that are unsafe to expose to any authed user and as such should actually default to "rule:admin_required" or something other than blank. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1649446/+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 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection)
In Cinder, the following drivers are using six.moves.http_client, which on python 2.7 I believe calls httplib: Location: cinder/cinder/volume/drivers/blockbridge.py:149 Location: cinder/cinder/volume/drivers/cloudbyte/cloudbyte.py:116 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:102 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:124 Location: cinder/cinder/volume/drivers/qnap.py:814 Location: cinder/cinder/volume/drivers/zadara.py:238 See reference of six.moves.http_client calling httplib here: https://pythonhosted.org/six/ Re-opening the bug. ** Changed in: cinder Status: Invalid => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: Triaged Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+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 1655494] Re: Newton scheduler clients should keep trying to report
Reviewed: https://review.openstack.org/418590 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=bbf9b431ee26e4064278e58bf9c177de48e8719a Submitter: Jenkins Branch:master commit bbf9b431ee26e4064278e58bf9c177de48e8719a Author: Dan Smith Date: Tue Jan 10 13:49:19 2017 -0800 Make placement client keep trying to connect In Newton, placement is optional and computes will stop even trying to connect to placement when they encounter an error or missing configuration. We really want them to keep trying so that enabling the service pre-upgrade does not require restarting all computes to start filling data. This patch removes the auto-disable logic and replaces it with a limited, but persistent warning to the logs about the required nature of placement for the upgrade. If we had messaged the upcoming requirement better, I think we could have been less chatty here. However, we know that it's not been received, so this patch periodically re-emits the warning and mentions the upgrade specifically. Closes-Bug: #1655494 Change-Id: Ie6387afeb239a20d39c00f519e8288f3b3a5e9cb ** Changed in: nova Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1655494 Title: Newton scheduler clients should keep trying to report Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: New Bug description: Newton scheduler clients will stop reporting any time they encounter a setup-related error, which isn't very operator-friendly for the ocata upgrade process. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655494/+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 1655013] Re: double assignment of user to group does not give error
Hi Martin, I agree that the feedback could be a bit better when a user is already a member of a specific group, but I'm not sure an error would be the best approach. Since we already return a 204 No Content response when a user is added to a group (or added when they are already a member). If we returned a 4XX response code for the same situation in the v3 API, we be breaking backwards compatibility. The good thing is the operation to add users to groups is idempotent even if they are already a member of the group. There is a openstackclient command to check membership based on the user and the group: > openstack group add user accounting bob bob added to group accounting > openstack group add user accounting bob bob added to group accounting > openstack group contains user accounting bob bob in group accounting Do you have tooling around the client that is expecting an error when a user already belongs to a group? I'm going to mark this as invalid for now since we won't be able to change the response code unless we introduce a microversion of the API (which keystone doesn't have support for yet) or we introduce a new API entirely (i.e. v4). ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1655013 Title: double assignment of user to group does not give error Status in OpenStack Identity (keystone): Invalid Bug description: Double group assignment. [student@ctrl ~(teacher)]$ openstack --os-project-name headoffice group add user newGroup student62 student62 added to group newGroup [lab3]:teacher@ [student@ctrl ~(teacher)]$ openstack --os-project-name headoffice group add user newGroup student62 student62 added to group newGroup [lab3]:teacher@ The second line should give an error that the user is already assigned to a group. I checked the database keystone.user_group_membership and there is only assignment there (happy that the problem was not that bad). [student@ctrl ~(teacher)]$ openstack --version openstack 2.3.0 [lab3]:teacher@ [student@ctrl ~(teacher)]$ uname -a Linux ctrl.lab3.stack 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [lab3]:teacher@ [student@ctrl ~(teacher)]$ cat /etc/*-release CentOS Linux release 7.3.1611 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/"; BUG_REPORT_URL="https://bugs.centos.org/"; CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" CentOS Linux release 7.3.1611 (Core) CentOS Linux release 7.3.1611 (Core) [lab3]:teacher@ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1655013/+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 1655761] [NEW] Resource Provider generation update missing
Public bug reported: Most of the methods that increase the generation for a resource provider also update the value of `generation` in the object that calls it, but there is one place where it was missing: the _set_allocations() method of the AllocationList class. This resulted in some ResourceProvider references having stale values for `generation`, which would cause a ConcurrentUpdateDetected exception to be raised. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: placement -- 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/1655761 Title: Resource Provider generation update missing Status in OpenStack Compute (nova): In Progress Bug description: Most of the methods that increase the generation for a resource provider also update the value of `generation` in the object that calls it, but there is one place where it was missing: the _set_allocations() method of the AllocationList class. This resulted in some ResourceProvider references having stale values for `generation`, which would cause a ConcurrentUpdateDetected exception to be raised. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655761/+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 1655727] [NEW] Improve compatibility with eventlet 0.20.1
Public bug reported: Eventlet 0.20.x added support for green version of subprocess, which however causes an issue with glance tests: glance.tests.functional.db.test_registry.TestRegistryDriver.test_image_create_bad_property -- Captured traceback: ~~~ Traceback (most recent call last): File "glance/tests/functional/db/test_registry.py", line 74, in setUp super(TestRegistryDriver, self).setUp() File "glance/tests/functional/db/base.py", line 95, in setUp super(TestDriver, self).setUp() File "glance/tests/functional/db/test_registry.py", line 62, in setUp api_version=2) File "glance/tests/functional/__init__.py", line 765, in start_with_retry **kwargs) File "glance/tests/functional/__init__.py", line 148, in start self.create_database() File "glance/tests/functional/__init__.py", line 230, in create_database expect_exit=True) File "glance/tests/utils.py", line 318, in execute result = process.communicate() File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate return self._communicate(input) File "/usr/lib64/python2.7/subprocess.py", line 1417, in _communicate stdout, stderr = self._communicate_with_poll(input) File "/usr/lib64/python2.7/subprocess.py", line 1447, in _communicate_with_poll poller = select.poll() AttributeError: 'module' object has no attribute 'poll' ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1655727 Title: Improve compatibility with eventlet 0.20.1 Status in Glance: New Bug description: Eventlet 0.20.x added support for green version of subprocess, which however causes an issue with glance tests: glance.tests.functional.db.test_registry.TestRegistryDriver.test_image_create_bad_property -- Captured traceback: ~~~ Traceback (most recent call last): File "glance/tests/functional/db/test_registry.py", line 74, in setUp super(TestRegistryDriver, self).setUp() File "glance/tests/functional/db/base.py", line 95, in setUp super(TestDriver, self).setUp() File "glance/tests/functional/db/test_registry.py", line 62, in setUp api_version=2) File "glance/tests/functional/__init__.py", line 765, in start_with_retry **kwargs) File "glance/tests/functional/__init__.py", line 148, in start self.create_database() File "glance/tests/functional/__init__.py", line 230, in create_database expect_exit=True) File "glance/tests/utils.py", line 318, in execute result = process.communicate() File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate return self._communicate(input) File "/usr/lib64/python2.7/subprocess.py", line 1417, in _communicate stdout, stderr = self._communicate_with_poll(input) File "/usr/lib64/python2.7/subprocess.py", line 1447, in _communicate_with_poll poller = select.poll() AttributeError: 'module' object has no attribute 'poll' To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1655727/+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 1655718] [NEW] nav bar intermittently does not display
Public bug reported: >From time to time, the left hand nav bar does not display correctly. This seems to occur a bit more frequently when you switch projects with different roles (admin to _member_ or back and fort), and also occurs when horizon is provided by several backend servers (behind a load balancer). I'm suspecting that this only occurs with several horizon nodes behind a LB, and could be a timing or caching issue - but it's not 100% clear when this does or does not occur. Rob had said he would look into this more. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1655718 Title: nav bar intermittently does not display Status in OpenStack Dashboard (Horizon): New Bug description: From time to time, the left hand nav bar does not display correctly. This seems to occur a bit more frequently when you switch projects with different roles (admin to _member_ or back and fort), and also occurs when horizon is provided by several backend servers (behind a load balancer). I'm suspecting that this only occurs with several horizon nodes behind a LB, and could be a timing or caching issue - but it's not 100% clear when this does or does not occur. Rob had said he would look into this more. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1655718/+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 1649341] Re: Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata"
** Changed in: tripleo Status: Fix Released => 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/1649341 Title: Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata" Status in OpenStack Compute (nova): Fix Released Status in puppet-nova: Fix Released Status in tripleo: In Progress Bug description: Trying to upgrade with recent trunk nova and puppet-nova gives this error: Notice: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: error: Cell mappings are not created, but required for Ocata. Please run nova-manage db simple_cell_setup before continuing. Error: /usr/bin/nova-manage api_db sync returned 1 instead of one of [0] Error: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: change from notrun to 0 failed: /usr/bin/nova-manage api_db sync returned 1 instead of one of [0] Debugging manually gives: $ sudo /usr/bin/nova-manage api_db sync error: Cell mappings are not created, but required for Ocata. Please run nova-manage db simple_cell_setup before continuing. but... $ sudo nova-manage db simple_cell_setup usage: nova-manage db [-h] {archive_deleted_rows,null_instance_uuid_scan,online_data_migrations,sync,version} ... nova-manage db: error: argument action: invalid choice: 'simple_cell_setup' (choose from 'archive_deleted_rows', 'null_instance_uuid_scan', 'online_data_migrations', 'sync', 'version') I tried adding openstack-nova* to the delorean-current whitelist, but with the latest nova packages there still appears to be this mismatch. [stack@instack /]$ rpm -qa | grep nova openstack-nova-conductor-15.0.0-0.20161212155146.909410c.el7.centos.noarch python-nova-15.0.0-0.20161212155146.909410c.el7.centos.noarch openstack-nova-scheduler-15.0.0-0.20161212155146.909410c.el7.centos.noarch puppet-nova-10.0.0-0.20161211003757.09b9f7b.el7.centos.noarch python2-novaclient-6.0.0-0.20161003181629.25117fa.el7.centos.noarch openstack-nova-api-15.0.0-0.20161212155146.909410c.el7.centos.noarch openstack-nova-cert-15.0.0-0.20161212155146.909410c.el7.centos.noarch openstack-nova-common-15.0.0-0.20161212155146.909410c.el7.centos.noarch openstack-nova-compute-15.0.0-0.20161212155146.909410c.el7.centos.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1649341/+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 1655710] [NEW] Query parameter validation using json schema - error messages
Public bug reported: A mechanism to validate query parameters using json schema was added in the following series: https://review.openstack.org/#/q/topic:bp/consistent-query- parameters-validation The resulting error messages aren't very user friendly though. For example, if you pass an invalid limit to os-keypairs list, you used to get a custom message rather than the obscure message generated by json schema. Before: webob.exc.HTTPBadRequest: Invalid input received: limit must be an integer After: nova.exception.ValidationError: Invalid input for query parameters 0. Value: abc. u'abc' does not match '^[0-9]*$' The exception raised also changed, which may be problematic for API consumers. We probably need another layer to transform these generated messages into something more user friendly, and perhaps consider raising HTTPBadRequest again with the nicer error message. ** Affects: nova Importance: Medium Status: Confirmed ** Tags: api -- 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/1655710 Title: Query parameter validation using json schema - error messages Status in OpenStack Compute (nova): Confirmed Bug description: A mechanism to validate query parameters using json schema was added in the following series: https://review.openstack.org/#/q/topic:bp/consistent-query- parameters-validation The resulting error messages aren't very user friendly though. For example, if you pass an invalid limit to os-keypairs list, you used to get a custom message rather than the obscure message generated by json schema. Before: webob.exc.HTTPBadRequest: Invalid input received: limit must be an integer After: nova.exception.ValidationError: Invalid input for query parameters 0. Value: abc. u'abc' does not match '^[0-9]*$' The exception raised also changed, which may be problematic for API consumers. We probably need another layer to transform these generated messages into something more user friendly, and perhaps consider raising HTTPBadRequest again with the nicer error message. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655710/+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 1655704] [NEW] unable to configure horizon default volume device name
Public bug reported: When an image has the attribute set to use "hw_scsi_model=virtio-scsi", then the default device name should be "sda". If the default device name remains 'vda', then it is not possible to add a second disk. This is because the LUN ID assigned to the second disk will conflict with the first if the device names are different. ** Affects: horizon Importance: Undecided Status: New ** Patch added: "LAUNCH_INSTANCE_DEFAULTS.patch" https://bugs.launchpad.net/bugs/1655704/+attachment/4802920/+files/LAUNCH_INSTANCE_DEFAULTS.patch -- 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/1655704 Title: unable to configure horizon default volume device name Status in OpenStack Dashboard (Horizon): New Bug description: When an image has the attribute set to use "hw_scsi_model=virtio- scsi", then the default device name should be "sda". If the default device name remains 'vda', then it is not possible to add a second disk. This is because the LUN ID assigned to the second disk will conflict with the first if the device names are different. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1655704/+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 1655471] Re: Update MTU on existing devices
Marking neutron bug as invalid as per [1]. The openstack-manuals as added as an affected project. Manuals need updating as per DoctImpact comment. [1] http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-triage-process ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1655471 Title: Update MTU on existing devices Status in neutron: Invalid Status in openstack-manuals: New Bug description: https://review.openstack.org/412462 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 52f31b0ddbb978402f65850bf41ceb409c560d4f Author: Ihar Hrachyshka Date: Tue Nov 29 22:24:29 2016 + Update MTU on existing devices This patch makes OVS and Linuxbridge interface drivers to set MTU on plug() attempt if the device already exists. This helps when network MTU changes (which happens after some configuration file changes). This will allow to update MTU values on agent restart, without the need to bind all ports to new nodes, that would involve migrating agents. It will also help in case when you have no other nodes to migrate to (in single node mode). Both OVS and Linuxbridge interface drivers are updated. Other drivers (in-tree IVS as well as 3party drivers) will use the default set_mtu implementation, that only warns about the missing feature (once per process startup). DocImpact suggest to restart agents after MTU config changes instead of rewiring router/DHCP ports. Related: If438e4816b425e6c5021a55567dcaaa77d1f Related: If09eda334cddc74910dda7a4fb498b7987714be3 Closes-Bug: #1649845 Change-Id: I3c6d6cb55c5808facec38f87114c2ddf548f05f1 (cherry picked from commit 5c8dffa7fb6c95a04a7b50c7d6e63c9a2729231b) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1655471/+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 1655670] Re: HTTP 404 when requesting /v3/domains/Default
I think that this is expected. When --domain Default is passed, openstackclient doesn't know what "Default" is -- id or name. So it tries to fetch domain with id Default, and when fails, then tries to fetch domain by name. This is definitely not keystone bug, and i think that it is not a bug in python-openstackclient, though i will add it to the bugreport. ** Also affects: python-openstackclient Importance: Undecided Status: New ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1655670 Title: HTTP 404 when requesting /v3/domains/Default Status in OpenStack Identity (keystone): Invalid Status in python-openstackclient: New Bug description: After running a Keystone test with Rally, I found a lot of HTTP 404 errors in the Apache2 access log when requesting /v3/domains/Default. 10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" I was able to reproduce this by executing the command "openstack project list --domain Default". I also found the appropriate entry in the Keystone log: 2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default 2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] Could not find domain: Default It works well when you use the domain id instead (openstack project list --domain default). Please find the debug output attached. There are two GET requests for /v3/domains/Default. Both of them get the 404. The next request uses another URL (/v3/domains?name=Default) which works well. I assume that's why you get the list even when the 404s occur. We use OpenStack Newton with Keystone version 10.0.0. Steps to reproduce: 1. Install DevStack 2. Execute "openstack --debug project list --domain Default" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1655670/+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 1524020] Re: DVRImpact: dvr_vmarp_table_update and dvr_update_router_add_vm is called for every port update instead of only when host binding or mac-address changes occur
** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1524020 Title: DVRImpact: dvr_vmarp_table_update and dvr_update_router_add_vm is called for every port update instead of only when host binding or mac- address changes occur Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: DVR arp update (dvr_vmarp_table_update) and dvr_update_router_add_vm called for every update_port if the mac_address changes or when update_devic_up is true. These functions should be called from _notify_l3_agent_port_update, only when a host binding for a service port changes or when a mac_address for the service port changes. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1524020/+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 1554876] Re: router not found warning logs in the L3 agent
** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1554876 Title: router not found warning logs in the L3 agent Status in neutron: Fix Released Bug description: The L3 agent during a normal tempest run will be filled with warnings like the following: 2016-03-08 10:10:30.465 18962 WARNING neutron.agent.l3.agent [-] Info for router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router cleanup 2016-03-08 10:10:34.197 18962 WARNING neutron.agent.l3.agent [-] Info for router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router cleanup 2016-03-08 10:10:35.535 18962 WARNING neutron.agent.l3.agent [-] Info for router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router cleanup 2016-03-08 10:10:43.025 18962 WARNING neutron.agent.l3.agent [-] Info for router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router cleanup 2016-03-08 10:10:47.029 18962 WARNING neutron.agent.l3.agent [-] Info for router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router cleanup This is completely normal as routers are deleted from the server during the data retrieval process of the L3 agent and should not be at the warning level. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1554876/+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 1655196] Re: Remove advertise_mtu config option
There don't appear to be any remaining references to advertise_mtu in the neutron tree. Looks like this affects openstack-manuals only. ** No longer affects: neutron ** Changed in: openstack-manuals Assignee: (unassigned) => John Davidge (john-davidge) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1655196 Title: Remove advertise_mtu config option Status in openstack-manuals: Confirmed Bug description: https://review.openstack.org/413567 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit b09a380f9579efc0779fb38db2cdb47b7b9e29d1 Author: Ihar Hrachyshka Date: Fri Dec 16 22:40:50 2016 + Remove advertise_mtu config option It was deprecated in Newton timeframe. Now we just clean it up from the tree. DocImpact: Any advertise_mtu option notions in documentation should be removed. UpgradeImpact: After upgrade, all DHCPv4 subnets will see the MTU option served via corresponding DHCPv4 option. Also, all IPv6 subnets connected to routers will see MTU set in Router Advertisement messages. NeutronLibImpact: This patch will break any 3party plugins that directly access the configuration option. Change-Id: I31e15018fe764de0fe4d6de7da3c1d9f2cc1d532 To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1655196/+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 1655670] [NEW] HTTP 404 when requesting /v3/domains/Default
Public bug reported: After running a Keystone test with Rally, I found a lot of HTTP 404 errors in the Apache2 access log when requesting /v3/domains/Default. 10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" I was able to reproduce this by executing the command "openstack project list --domain Default". I also found the appropriate entry in the Keystone log: 2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default 2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] Could not find domain: Default It works well when you use the domain id instead (openstack project list --domain default). Please find the debug output attached. There are two GET requests for /v3/domains/Default. Both of them get the 404. The next request uses another URL (/v3/domains?name=Default) which works well. I assume that's why you get the list even when the 404s occur. We use OpenStack Newton with Keystone version 10.0.0. Steps to reproduce: 1. Install DevStack 2. Execute "openstack --debug project list --domain Default" ** Affects: keystone Importance: Undecided Status: New ** Attachment added: "OpenStack command debug output" https://bugs.launchpad.net/bugs/1655670/+attachment/4802881/+files/404_project_list.txt -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1655670 Title: HTTP 404 when requesting /v3/domains/Default Status in OpenStack Identity (keystone): New Bug description: After running a Keystone test with Rally, I found a lot of HTTP 404 errors in the Apache2 access log when requesting /v3/domains/Default. 10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" 10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default HTTP/1.1" 404 91 "-" "python-keystoneclient" I was able to reproduce this by executing the command "openstack project list --domain Default". I also found the appropriate entry in the Keystone log: 2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default 2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default default] Could not find domain: Default It works well when you use the domain id instead (openstack project list --domain default). Please find the debug output attached. There are two GET requests for /v3/domains/Default. Both of them get the 404. The next request uses another URL (/v3/domains?name=Default) which works well. I assume that's why you get the list even when the 404s occur. We use OpenStack Newton with Keystone version 10.0.0. Steps to reproduce: 1. Install DevStack 2. Execute "openstack --debug project list --domain Default" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1655670/+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 1655662] [NEW] libvirt xen hvm guests can't hot plug (attach detach) default block devices
Public bug reported: Currently default disk bus for libvirt+Xen HVM guests is "ide", which not allow hot reconfiguration. So images without special metadata property specifying bus can't be attached or detached. https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250 At the same time QEMU/KVM guests have "virtio" as default disk bus for disk which is QEMU analog of "xen" bus for XEN. Fix looks trivial and require only delete XEN HVM specific part to return "xen" as default part in all cases. User will be able to use other buses by metadata and only when it's really required. ** Affects: nova Importance: Undecided Status: New ** Tags: libvirt xen ** Tags added: libvirt xen -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1655662 Title: libvirt xen hvm guests can't hot plug (attach detach) default block devices Status in OpenStack Compute (nova): New Bug description: Currently default disk bus for libvirt+Xen HVM guests is "ide", which not allow hot reconfiguration. So images without special metadata property specifying bus can't be attached or detached. https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250 At the same time QEMU/KVM guests have "virtio" as default disk bus for disk which is QEMU analog of "xen" bus for XEN. Fix looks trivial and require only delete XEN HVM specific part to return "xen" as default part in all cases. User will be able to use other buses by metadata and only when it's really required. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655662/+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 1593571] Re: [Mitaka] 'AttributeError: name' when using multiple domain with LDAP driver
** Also affects: openstack-dashboard (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1593571 Title: [Mitaka] 'AttributeError: name' when using multiple domain with LDAP driver Status in OpenStack Dashboard (Horizon): Fix Released Status in openstack-dashboard package in Ubuntu: New Bug description: I get 'AttributeError: name' when using multiple domain with LDAP driver. Specifically, when I click 'Create Project', 'Manage Members', 'Modify Groups', 'Edit Project' and 'Modify Quotas' button on the 'Projects' page of 'Identify' menu, horizon makes those error messages below. It doesn't seem to be related to keystone since there is no error message from keystone node and I can do those operations using CLI without any problem. ==> /var/log/apache2/error.log <== [97/7522] [Fri Jun 17 14:44:57.440997 2016] [wsgi:error] [pid 93971:tid 140574614624000] Problem instantiating action class. [Fri Jun 17 14:44:57.441049 2016] [wsgi:error] [pid 93971:tid 140574614624000] Traceback (most recent call last): [Fri Jun 17 14:44:57.441060 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/workflows/base.py", line 370, in action [Fri Jun 17 14:44:57.441083 2016] [wsgi:error] [pid 93971:tid 140574614624000] context) [Fri Jun 17 14:44:57.441123 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/identity/projects/workflows.py", line 323, in __init__ [Fri Jun 17 14:44:57.441141 2016] [wsgi:error] [pid 93971:tid 140574614624000] groups_list = [(group.id, group.name) for group in all_groups] [Fri Jun 17 14:44:57.441157 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 491, in __getattr__ [Fri Jun 17 14:44:57.441182 2016] [wsgi:error] [pid 93971:tid 140574614624000] raise AttributeError(k) [Fri Jun 17 14:44:57.441199 2016] [wsgi:error] [pid 93971:tid 140574614624000] AttributeError: name [Fri Jun 17 14:44:57.442367 2016] [wsgi:error] [pid 93971:tid 140574614624000] Internal Server Error: /horizon/identity/04e7fe0cfb19418a9ec2eacfe1d334d5/update/ [Fri Jun 17 14:44:57.442389 2016] [wsgi:error] [pid 93971:tid 140574614624000] Traceback (most recent call last): [Fri Jun 17 14:44:57.442420 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 164, in get_response [Fri Jun 17 14:44:57.442439 2016] [wsgi:error] [pid 93971:tid 140574614624000] response = response.render() [Fri Jun 17 14:44:57.442455 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/response.py", line 158, in render [Fri Jun 17 14:44:57.442480 2016] [wsgi:error] [pid 93971:tid 140574614624000] self.content = self.rendered_content [Fri Jun 17 14:44:57.442497 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/response.py", line 135, in rendered_content [Fri Jun 17 14:44:57.442514 2016] [wsgi:error] [pid 93971:tid 140574614624000] content = template.render(context, self._request) [Fri Jun 17 14:44:57.442530 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/backends/django.py", line 74, in render [Fri Jun 17 14:44:57.442555 2016] [wsgi:error] [pid 93971:tid 140574614624000] return self.template.render(context) [Fri Jun 17 14:44:57.442579 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 210, in render [Fri Jun 17 14:44:57.442596 2016] [wsgi:error] [pid 93971:tid 140574614624000] return self._render(context) [Fri Jun 17 14:44:57.443601 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 202, in _render [Fri Jun 17 14:44:57.443632 2016] [wsgi:error] [pid 93971:tid 140574614624000] return self.nodelist.render(context) [Fri Jun 17 14:44:57.443649 2016] [wsgi:error] [pid 93971:tid 140574614624000] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render [Fri Jun 17 14:44:57.443666 2016] [wsgi:error] [pid 93971:tid 140574614624000] bit = self.render_node(node, context) [Fri Jun 17 14:44:57.443696 2016] [wsgi:error] [pid 93971:tid 140574614624000]
[Yahoo-eng-team] [Bug 1655610] [NEW] alembic_version table has no primary key
Public bug reported: Currently alembic_version table in the neutron db has no primary key. Which is a bad thing, if you consider to use Galera as a database, since it requires primary keys in all tables. For example, during the "INFO [alembic.runtime.migration] Running upgrade -> kilo, kilo_initial" migration you will get the: oslo_db.exception.DBError: (pymysql.err.InternalError) (1105, u'Percona- XtraDB-Cluster prohibits use of DML command on a table (neutron.alembic_version) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u"INSERT INTO alembic_version (version_num) VALUES ('kilo')"] ** Affects: neutron Importance: Undecided Assignee: Ann Taraday (akamyshnikova) Status: New ** Tags: db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1655610 Title: alembic_version table has no primary key Status in neutron: New Bug description: Currently alembic_version table in the neutron db has no primary key. Which is a bad thing, if you consider to use Galera as a database, since it requires primary keys in all tables. For example, during the "INFO [alembic.runtime.migration] Running upgrade -> kilo, kilo_initial" migration you will get the: oslo_db.exception.DBError: (pymysql.err.InternalError) (1105, u 'Percona-XtraDB-Cluster prohibits use of DML command on a table (neutron.alembic_version) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u"INSERT INTO alembic_version (version_num) VALUES ('kilo')"] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1655610/+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 1655605] [NEW] metadata proxy won't start in dhcp namespace when network(subnet) is removed from router
Public bug reported: When adding network(subnet) into router immediately after creating network(subnet), there is no metadata proxy process created in dhcp namespace to listen on port 80. It causes problem when deleted network(subnet) from router: it won't call metadata service successfully until restarting dhcp service. Restarting dhcp service is just a workaround and is not acceptable as solution. This problem is introduced in Newton release. When adding network, it will check whether the network has isolated ipv4 subnet. It queries all ports belonging to the network, and see whether there is any port used as gateway. if yes, then it thinks the subnet is not isolated. If we add subnet to router immediately after creating subnet, the process of network creation( creating metadata proxy) and the process of adding subnet to interface happens at the same time. The seconds process creates port as gateway quickly and then the first process checks and treats it no isolated, and then will kill metadata proxy created soon earlier. # /etc/neutron/dhcp_agent.ini enable_isolated_metadata = True enable_metadata_network = True #execute the following commands in batch without interruption. neutron net-create network_1 neutron subnet-create --name subnet_1 network_1 172.60.0.0/24 neutron router-interface-add default subnet_1 # there is no 80 port. ip netns exec qdhcp-c5791b7d-ec3e-4e96-9a32-b9d1217ed330 netstat -tunlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 172.16.255.2:53 0.0.0.0:* LISTEN 16926/dnsmasq tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN 16926/dnsmasq tcp6 0 0 fe80::f816:3eff:fe80:53 :::* LISTEN 16926/dnsmasq udp 0 0 172.16.255.2:53 0.0.0.0:* 16926/dnsmasq udp 0 0 169.254.169.254:53 0.0.0.0:* 16926/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 16926/dnsmasq udp6 0 0 :::547 :::* 16926/dnsmasq udp6 0 0 fe80::f816:3eff:fe80:53 :::* 16926/dnsmasq ** 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/1655605 Title: metadata proxy won't start in dhcp namespace when network(subnet) is removed from router Status in neutron: New Bug description: When adding network(subnet) into router immediately after creating network(subnet), there is no metadata proxy process created in dhcp namespace to listen on port 80. It causes problem when deleted network(subnet) from router: it won't call metadata service successfully until restarting dhcp service. Restarting dhcp service is just a workaround and is not acceptable as solution. This problem is introduced in Newton release. When adding network, it will check whether the network has isolated ipv4 subnet. It queries all ports belonging to the network, and see whether there is any port used as gateway. if yes, then it thinks the subnet is not isolated. If we add subnet to router immediately after creating subnet, the process of network creation( creating metadata proxy) and the process of adding subnet to interface happens at the same time. The seconds process creates port as gateway quickly and then the first process checks and treats it no isolated, and then will kill metadata proxy created soon earlier. # /etc/neutron/dhcp_agent.ini enable_isolated_metadata = True enable_metadata_network = True #execute the following commands in batch without interruption. neutron net-create network_1 neutron subnet-create --name subnet_1 network_1 172.60.0.0/24 neutron router-interface-add default subnet_1 # there is no 80 port. ip netns exec qdhcp-c5791b7d-ec3e-4e96-9a32-b9d1217ed330 netstat -tunlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 172.16.255.2:53 0.0.0.0:* LISTEN 16926/dnsmasq tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN 16926/dnsmasq tcp6 0 0 fe80::f816:3eff:fe80:53 :::* LISTEN 16926/dnsmasq udp 0 0 172.16.255.2:53 0.0.0.0:* 16926/dnsmasq udp 0 0 169.254.169.254:53 0.0.0.0:* 16926/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 16926/dnsmasq udp6
[Yahoo-eng-team] [Bug 1655393] Re: manila-ui quotas override part of the default quotas
** Project changed: manila-ui => horizon -- 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/1655393 Title: manila-ui quotas override part of the default quotas Status in OpenStack Dashboard (Horizon): In Progress Bug description: Versions affected: mitaka and higher. Under Admin -> Defaults -> Update defaults Due to manila-ui overriding the default quotas from horizon, it makes the "Update Default Quotas" workflow miss some initial values ('Key Pairs' and 'Length of Injected File Path') This is due to this line of code: https://github.com/openstack/manila- ui/blob/stable/mitaka/manila_ui/dashboards/project/shares/__init__.py#L81 quotas.QUOTA_FIELDS = quotas.QUOTA_FIELDS + MANILA_QUOTA_FIELDS This assumes that all the quotas available are in quotas.QUOTA_FIELDS but unfortunately, for some historical reason Im sure, there is some extra quotas not available on that tuple: https://github.com/openstack/horizon/blob/master/openstack_dashboard/usage/quotas.py#L44 MISSING_QUOTA_FIELDS = ("key_pairs", "injected_file_path_bytes",) This causes the quotas to appear correctly when viewing them on Admin -> Defaults, but when editing their values get lost. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1655393/+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 1655393] [NEW] manila-ui quotas override part of the default quotas
You have been subscribed to a public bug: Versions affected: mitaka and higher. Under Admin -> Defaults -> Update defaults Due to manila-ui overriding the default quotas from horizon, it makes the "Update Default Quotas" workflow miss some initial values ('Key Pairs' and 'Length of Injected File Path') This is due to this line of code: https://github.com/openstack/manila- ui/blob/stable/mitaka/manila_ui/dashboards/project/shares/__init__.py#L81 quotas.QUOTA_FIELDS = quotas.QUOTA_FIELDS + MANILA_QUOTA_FIELDS This assumes that all the quotas available are in quotas.QUOTA_FIELDS but unfortunately, for some historical reason Im sure, there is some extra quotas not available on that tuple: https://github.com/openstack/horizon/blob/master/openstack_dashboard/usage/quotas.py#L44 MISSING_QUOTA_FIELDS = ("key_pairs", "injected_file_path_bytes",) This causes the quotas to appear correctly when viewing them on Admin -> Defaults, but when editing their values get lost. ** Affects: horizon Importance: Undecided Assignee: Itxaka Serrano (itxakaserrano) Status: In Progress ** Tags: newton-backport-potential -- manila-ui quotas override part of the default quotas https://bugs.launchpad.net/bugs/1655393 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). -- 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 1654990] Re: Vm creation getting failed with image not found error
This doesn't appear to be a nova issue, the keystone error in c#2 suggesting an issue with memcached in your environment that in turn is bubbling back up to Glance and finally Nova. Liberty is also an unsupported release at present so I'm marking this as invalid for now but feel free to change this if you are able to reproduce this against a supported release. ** 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/1654990 Title: Vm creation getting failed with image not found error Status in OpenStack Compute (nova): Invalid Bug description: We have Liberty setup with all services in HA. Sometimes vm creation is getting failed throwing below error. We are getting this error randomly. " nCould not find image fdc-centos7-image: 500 Internal Server Error Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n\n\n " Below is the nova api log: 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions [req-6f2cacb2-c36b-464e-b816-3caad8c24746 3612616185a748f788fb0532729ccc3a 5896939c506840c2bf083cb1100bee2b - - -] Unexpected exception in API method 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, in wrapped 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/images.py", line 145, in detail 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions **page_params) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/image/api.py", line 68, in get_all 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return session.detail(context, **kwargs) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 284, in detail 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions for image in images: 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 254, in list 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions for image in paginate(params, return_request_id): 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 238, in paginate 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions images, resp = self._list(url, "images") 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 63, in _list 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions resp, body = self.client.get(url) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 280, in get 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return self._request('GET', url, **kwargs) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 272, in _request 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions resp, body_iter = self._handle_response(resp) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 93, in _handle_response 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions raise exc.from_response(resp, resp.content) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions HTTPInternalServerError: 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation. (HTTP 500) 2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions 2017-01-09 05:19:00.583 592 INFO nova.api.openstack.wsgi [req-6f2cacb2-c36b-464e-b816-3caad8c24746 3612616185a748f788fb0532729ccc3a 5896939c506840c2bf083cb1100bee2b - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1654990/+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/ListHel
[Yahoo-eng-team] [Bug 1655579] [NEW] Attached port with disabled security does not work properly
Public bug reported: When I attach port with disabled security to a vm, I am not able to use this port. Steps to reproduce: 1. Create port and disable security: neutron port-create --name test-sec-group --no-security-groups neutron port-update --port-security-enabled=False 2. Attach port to vm nova interface-attach --port-id After this steps I am unable to use this port on the vm (for example obtain dhcp lease). The cause that I identified is that after this steps the iptables on the host with vm is not configured properly. I can't see rules that should be there: -A neutron-openvswi-FORWARD -m physdev --physdev-out --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT -A neutron-openvswi-FORWARD -m physdev --physdev-in --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT -A neutron-openvswi-INPUT -m physdev --physdev-in --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT When I add this rules manually, everything works fine. Another scenario when everything works fine: change steps order - create port, attach it and then disable security. My environment: * Openstack mitaka on centos 7 * neutron version: neutron-8.2.0 * nova version: nova-13.1.1 ** 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/1655579 Title: Attached port with disabled security does not work properly Status in neutron: New Bug description: When I attach port with disabled security to a vm, I am not able to use this port. Steps to reproduce: 1. Create port and disable security: neutron port-create --name test-sec-group --no-security-groups neutron port-update --port-security-enabled=False 2. Attach port to vm nova interface-attach --port-id After this steps I am unable to use this port on the vm (for example obtain dhcp lease). The cause that I identified is that after this steps the iptables on the host with vm is not configured properly. I can't see rules that should be there: -A neutron-openvswi-FORWARD -m physdev --physdev-out --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT -A neutron-openvswi-FORWARD -m physdev --physdev-in --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT -A neutron-openvswi-INPUT -m physdev --physdev-in --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT When I add this rules manually, everything works fine. Another scenario when everything works fine: change steps order - create port, attach it and then disable security. My environment: * Openstack mitaka on centos 7 * neutron version: neutron-8.2.0 * nova version: nova-13.1.1 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1655579/+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 1655567] [NEW] DHCPv6 failures with "address already allocated in subnet" error
Public bug reported: Test failures with the DHCPv6 error from multiple test methods. Use query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22already%20allocated%20in%20subnet%5C%22 An example: == 2017-01-11 05:00:04.479808 | Failed 1 tests - output below: 2017-01-11 05:00:04.479858 | == 2017-01-11 05:00:04.479883 | 2017-01-11 05:00:04.479962 | tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_stateless_eui64[id-e5517e62-6f16-430d-a672-f80875493d4c] 2017-01-11 05:00:04.480056 | -- 2017-01-11 05:00:04.480082 | 2017-01-11 05:00:04.480113 | Captured traceback: 2017-01-11 05:00:04.480154 | ~~~ 2017-01-11 05:00:04.480204 | Traceback (most recent call last): 2017-01-11 05:00:04.480283 | File "tempest/api/network/test_dhcp_ipv6.py", line 109, in test_dhcpv6_stateless_eui64 2017-01-11 05:00:04.480415 | real_ip, eui_ip = self._get_ips_from_subnet(**kwargs) 2017-01-11 05:00:04.480486 | File "tempest/api/network/test_dhcp_ipv6.py", line 90, in _get_ips_from_subnet 2017-01-11 05:00:04.480551 | subnet = self.create_subnet(self.network, **kwargs) 2017-01-11 05:00:04.480607 | File "tempest/api/network/base.py", line 179, in create_subnet 2017-01-11 05:00:04.481118 | **kwargs) 2017-01-11 05:00:04.481198 | File "tempest/lib/services/network/subnets_client.py", line 27, in create_subnet 2017-01-11 05:00:04.481260 | return self.create_resource(uri, post_data) 2017-01-11 05:00:04.481756 | File "tempest/lib/services/network/base.py", line 60, in create_resource 2017-01-11 05:00:04.481830 | resp, body = self.post(req_uri, req_post_data) 2017-01-11 05:00:04.481887 | File "tempest/lib/common/rest_client.py", line 276, in post 2017-01-11 05:00:04.481946 | return self.request('POST', url, extra_headers, headers, body, chunked) 2017-01-11 05:00:04.482000 | File "tempest/lib/common/rest_client.py", line 664, in request 2017-01-11 05:00:04.482042 | self._error_checker(resp, resp_body) 2017-01-11 05:00:04.482098 | File "tempest/lib/common/rest_client.py", line 776, in _error_checker 2017-01-11 05:00:04.482145 | raise exceptions.Conflict(resp_body, resp=resp) 2017-01-11 05:00:04.482204 | tempest.lib.exceptions.Conflict: An object with that identifier already exists 2017-01-11 05:00:04.482325 | Details: {u'detail': u'', u'message': u'IP address 2003::f816:3eff:fe18:34ee already allocated in subnet 181627ba-b8ff-49c2-b97d-21763a0b572c', u'type': u'IpAddressAlreadyAllocated'} ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ipv6 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1655567 Title: DHCPv6 failures with "address already allocated in subnet" error Status in neutron: New Bug description: Test failures with the DHCPv6 error from multiple test methods. Use query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22already%20allocated%20in%20subnet%5C%22 An example: == 2017-01-11 05:00:04.479808 | Failed 1 tests - output below: 2017-01-11 05:00:04.479858 | == 2017-01-11 05:00:04.479883 | 2017-01-11 05:00:04.479962 | tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_stateless_eui64[id-e5517e62-6f16-430d-a672-f80875493d4c] 2017-01-11 05:00:04.480056 | -- 2017-01-11 05:00:04.480082 | 2017-01-11 05:00:04.480113 | Captured traceback: 2017-01-11 05:00:04.480154 | ~~~ 2017-01-11 05:00:04.480204 | Traceback (most recent call last): 2017-01-11 05:00:04.480283 | File "tempest/api/network/test_dhcp_ipv6.py", line 109, in test_dhcpv6_stateless_eui64 2017-01-11 05:00:04.480415 | real_ip, eui_ip = self._get_ips_from_subnet(**kwargs) 2017-01-11 05:00:04.480486 | File "tempest/api/network/test_dhcp_ipv6.py", line 90, in _get_ips_from_subnet 2017-01-11 05:00:04.480551 | subnet = self.create_subnet(self.network, **kwargs) 2017-01-11 05:00:04.480607 | File "tempest/api/network/base.py", line 179, in create_subnet 2017-01-11 05:00:04.481118 | **kwargs) 2017-01-11 05:00:04.481198 | File "tempest/lib/services/network/subnets_client.py", line 27, in create_subnet 2017-01-11 05:00:04.481260 | return self.create_resource(uri, post_data) 2017-01-11 05:00:04.481756 | File "tempest/lib/services/network/base.py", line 60, in create_resource 2017-01-11 05:00:0
[Yahoo-eng-team] [Bug 1655560] [NEW] Horizon doesn't obtain domain scoped tokens for users coming through websso
Public bug reported: We have a Mitaka deployment in which users can login using an external SSO service and the Keystone external authentication protocol and are mapped to a Keytone domain. Domain admin users from that domain can't perform any admin operations in the frontend because Horizon doesn't obtain a domain scoped token. With external authentication, Keystone tokens always have the user domain present, so this shouldn't be an issue in Horizon. In my opinion, the bug is in the django_openstack_auth project. Here, on the websso path, I think the user domain is expected to be provided by the user in the login page, which, of course, isn't possible for websso. As a solution, the unscoped Keystone token can be checked for the user domain. I have attached a patch for the 2.2.1 tag of django_openstack_auth. Seeing code here hasn't been modified in a long time, the bug should manifest itself in the newest version of Horizon. ** Affects: horizon Importance: Undecided Status: New ** Tags: dashboard-core ** Patch added: "Patch django_openstack_auth tag 2.2.1" https://bugs.launchpad.net/bugs/1655560/+attachment/4802757/+files/websso_domain.patch ** Description changed: We have a Mitaka deployment in which users can login using an external SSO service and the Keystone external authentication protocol and are mapped to a Keytone domain. Domain admin users from that domain can't perform any admin operations in the frontend because Horizon doesn't obtain a domain scoped token. With external authentication, Keystone tokens always have the user domain present, so this shouldn't be an issue in Horizon. In my opinion, the bug is in the django_openstack_auth project. Here, on the websso path, I think the user domain is expected to be provided by the user in the login page, which, of course, isn't possible for websso. As a solution, the unscoped Keystone token can be checked for the user domain. I have attached a patch for the 2.2.1 tag of django_openstack_auth. Seeing code here hasn't been modified in a long time, the bug should - manifest in the newest version of Horizon. + manifest itself in the newest version of Horizon. -- 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/1655560 Title: Horizon doesn't obtain domain scoped tokens for users coming through websso Status in OpenStack Dashboard (Horizon): New Bug description: We have a Mitaka deployment in which users can login using an external SSO service and the Keystone external authentication protocol and are mapped to a Keytone domain. Domain admin users from that domain can't perform any admin operations in the frontend because Horizon doesn't obtain a domain scoped token. With external authentication, Keystone tokens always have the user domain present, so this shouldn't be an issue in Horizon. In my opinion, the bug is in the django_openstack_auth project. Here, on the websso path, I think the user domain is expected to be provided by the user in the login page, which, of course, isn't possible for websso. As a solution, the unscoped Keystone token can be checked for the user domain. I have attached a patch for the 2.2.1 tag of django_openstack_auth. Seeing code here hasn't been modified in a long time, the bug should manifest itself in the newest version of Horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1655560/+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 1655558] [NEW] vmware create vm instance from snapshot error
Public bug reported: my environment is: vcenter version 6.0, vsan version 6.0, and the neutron use vmware's NSX! openstack is deploy by fuel 9.0,then the openstack version is mitaka! when i create a snapshot from vm instance,and the deploy the new vm instance from the snapshot ,get the error: 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images Traceback (most recent call last): 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py", line 186, in image_transfer 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images data = read_handle.read(CHUNK_SIZE) 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images File "/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py", line 645, in read 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images data = next(self._iter) 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images File "/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py", line 653, in get_next 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images for data in self._glance_read_iter: 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images File "/usr/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 477, in __iter__ 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images for chunk in self.iterable: 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images File "/usr/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 435, in integrity_iter 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images (md5sum, checksum)) 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images IOError: [Errno 32] Corrupt image download. Checksum was 4aeaba2179866eb9d9b801d679964dfa expected f28c8836cf65c087e8b43f4c798477f6 2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images <183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.899 4011 DEBUG oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Getting lease state for https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:455 <183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.900 4011 DEBUG oslo_vmware.api [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Waiting for function oslo_vmware.api._invoke_api to return. func /usr/lib/python2.7/dist-packages/oslo_vmware/api.py:122 <183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.914 4011 DEBUG oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Lease for https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk is in state: ready. close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:464 <183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.915 4011 DEBUG oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Releasing lease for https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:466 <183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.916 4011 DEBUG oslo_vmware.api [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Waiting for function oslo_vmware.api._invoke_api to return. func /usr/lib/python2.7/dist-packages/oslo_vmware/api.py:122 <183>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.842 4011 DEBUG oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Closed VMDK write handle for https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:481 <183>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.843 4011 DEBUG oslo_concurrency.lockutils [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Releasing semaphore "[WYYVSANDATASTOR] vcenter-WyyCluster_base/121e0150-88a8-440f-9ce4-2f5a1bceae2d/121e0150-88a8-440f-9ce4-2f5a1bceae2d.vmdk" lock /usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225 <179>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.844 4011 ERROR nova.compute.manager [req-985a3617-9d0b-4ee7-926d-49e11578a811 a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] [instance: c6cea137-8a09-4960-bc01-8612a60fe250] Instance failed to spawn 2016-12-22 07:12:03.844 4011 ERROR nova.compute.manager [instance: c6cea137-8a09-4960-bc01-8612a60fe250]
[Yahoo-eng-team] [Bug 1649793] Re: vmware image download error
** Changed in: nova Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1649793 Title: vmware image download error Status in OpenStack Compute (nova): Invalid Bug description: when create vm in openstack success,then i task a snapshot from the vm ,and then use the snapshot to deploy vm error. i add some log in the code ,found write_handle only transfer several times ,will break off. the error msg: 2016-12-14 03:37:20.138 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:20.140 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:20.142 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:20.144 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:20.464 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:21.811 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:42.449 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:42.451 26646 ERROR nova.virt.vmwareapi.images [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 1--- 2016-12-14 03:37:42.508 26646 DEBUG oslo_vmware.rw_handles [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] Getting lease state for https://192.168.103.86/nfc/52c6f60a-50c4-e232-7659-b0927f1dd866/disk-0.vmdk. close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:459 2016-12-14 03:37:42.509 26646 DEBUG oslo_vmware.rw_handles [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] --start close- close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:460 2016-12-14 03:37:42.510 26646 DEBUG oslo_vmware.rw_handles [req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 3885b586a8014286bc07b24df332afab - - -] [(, '/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py', 461, 'close', [' LOG.debug(inspect.stack())\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py', 208, 'image_transfer', ['write_handle.close()\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py', 359, 'fetch_image_stream_optimized', ['image_transfer(read_handle, write_handle)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 429, '_fetch_image_as_vapp', ['self._root_resource_pool)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 614, '_fetch_image_if_missing', ['im age_fetch(context, vi, tmp_image_ds_loc)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 751, 'spawn', ['self._fetch_image_if_missing(context, vi)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py', 381, 'spawn', [' admin_password, network_info, block_device_info)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 2064, '_build_and_run_instance', [' block_device_info=block_device_info)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 1926, '_do_build_and_run_instance', ['filter_properties)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 375, 'decorated_function', ['return function(self, context, *args, **kwargs)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 409, 'decorated_function', ['return function(self, context, *arg