[Yahoo-eng-team] [Bug 1540208] Re: CSRF mechanism is not safe.
My feedback from Django project is, it's not exploitable. If this is an issue, it's a Django one, not specific to Horizon. ** Changed in: horizon Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1540208 Title: CSRF mechanism is not safe. Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Security Advisory: Incomplete Bug description: I'm using burp suite to check secure of horizon 8.0.0.0. CSRF mechanism is not safe. I saw : csrftoken equals with csrfmidlewaretoken ==> the reques is valid. Example: Do update network's name. The first request: - I got csrftoken and csrfmidlewaretoken: PvVPmsOEqepSWnWgJa1GKYtBxcSXMTu1 - network's name : attt_net_test_129 then I change csrftoken and csrfmidlewaretoken to "1" , network 's name value to "attt_net_test_121" Final, do send request ==> Network is updated succesfuly. (attach file) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1540208/+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 1540794] [NEW] deprecate signing config options
Public bug reported: PKI tokens have been deprecated, so should all the signing related config options: https://github.com/openstack/keystone/blob/master/keystone/common/config.py#L347-L374 ** Affects: keystone Importance: Undecided Status: New ** Changed in: keystone Milestone: None => mitaka-3 -- 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/1540794 Title: deprecate signing config options Status in OpenStack Identity (keystone): New Bug description: PKI tokens have been deprecated, so should all the signing related config options: https://github.com/openstack/keystone/blob/master/keystone/common/config.py#L347-L374 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1540794/+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 1539505] Re: Font file not found
** Changed in: horizon Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1539505 Title: Font file not found Status in OpenStack Dashboard (Horizon): Invalid Bug description: [29/Jan/2016 09:57:30] "GET /i18n/js/horizon+openstack_dashboard/ HTTP/1.1" 200 2372 Not Found: /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.woff2 [29/Jan/2016 09:57:30] "GET /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.woff2?v=4.3.0 HTTP/1.1" 404 4718 Not Found: /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.woff [29/Jan/2016 09:57:30] "GET /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.woff?v=4.3.0 HTTP/1.1" 404 4715 Not Found: /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.ttf [29/Jan/2016 09:57:30] "GET /dashboard/static/horizon/lib/font-awesome/fonts/fontawesome-webfont.ttf?v=4.3.0 HTTP/1.1" 404 4712 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1539505/+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 1535231] Re: md-meta with case insensitive string has problem when creating
We can add some additional info about case-insensitivity to exception message but that must be fixed in glance. ** Also affects: glance Importance: Undecided Status: New ** No longer affects: python-glanceclient ** Changed in: glance Status: New => Confirmed ** Changed in: glance Importance: Undecided => Low ** Changed in: glance Assignee: (unassigned) => Kairat Kushaev (kkushaev) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1535231 Title: md-meta with case insensitive string has problem when creating Status in Glance: Confirmed Bug description: [Summary] md-meta with case sensitive has problem when creating [Topo] devstack all-in-one node [Description and expect result] can create case sensitive md-meta [Reproduceable or not] reproduceable [Recreate Steps] 1) there is a md-tag named "ab" for namespace "new-ns": stack@45-59:~/devstack$ glance md-tag-create --name ab new-ns ++--+ | Property | Value| ++--+ | created_at | 2016-01-18T16:36:13Z | | name | ab | | updated_at | 2016-01-18T16:36:13Z | ++--+ stack@45-59:~/devstack$ glance md-tag-list new-ns +--+ | name | +--+ | ab | +--+ 2)if create a new md-tag named "AB", conflict occur: >>>ISSUE stack@45-59:~/devstack$ glance md-tag-create --name AB new-ns 409 Conflict: A metadata tag with name=AB already exists in namespace=new-ns. stack@45-59:~/devstack$ 3)but if there is no md-tag "ab", the md-tag "AB" can be created. stack@45-59:~/devstack$ glance md-tag-delete new-ns ab stack@45-59:~/devstack$ stack@45-59:~/devstack$ glance md-tag-list new-ns +--+ | name | +--+ +--+ stack@45-59:~/devstack$ glance md-tag-create --name AB new-ns ++--+ | Property | Value| ++--+ | created_at | 2016-01-18T16:37:20Z | | name | AB | | updated_at | 2016-01-18T16:37:20Z | ++--+ [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1535231/+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 1540844] [NEW] ML2's assumptions about transactions should be explicit
Public bug reported: The create/update/delete of the core resource in ML2 all assume that they will not be called inside of a transaction because they notify drivers with a postcommit call before returning. Calling ML2 with a session already in a transaction leads to unexpected behavior (e.g. no notifications to driver on a rollback) so we should enforce this assumption in code. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1540844 Title: ML2's assumptions about transactions should be explicit Status in neutron: In Progress Bug description: The create/update/delete of the core resource in ML2 all assume that they will not be called inside of a transaction because they notify drivers with a postcommit call before returning. Calling ML2 with a session already in a transaction leads to unexpected behavior (e.g. no notifications to driver on a rollback) so we should enforce this assumption in code. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540844/+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 1393391] Re: neutron-openvswitch-agent stuck on no queue 'q-agent-notifier-port-update_fanout..
** Also affects: neutron (Ubuntu) Importance: Undecided Status: New ** Also affects: neutron (Ubuntu Trusty) 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/1393391 Title: neutron-openvswitch-agent stuck on no queue 'q-agent-notifier-port- update_fanout.. Status in neutron: Confirmed Status in neutron package in Ubuntu: New Status in neutron source package in Trusty: New Bug description: Under an HA deployment, neutron-openvswitch-agent can get stuck when receiving a close command on a fanout queue the agent is not subscribed to. It stops responding to any other messages, so it stops effectively working at all. 2014-11-11 10:27:33.092 3027 INFO neutron.common.config [-] Logging enabled! 2014-11-11 10:27:34.285 3027 INFO neutron.openstack.common.rpc.common [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Connected to AMQP server on vip-rabbitmq:5672 2014-11-11 10:27:34.370 3027 INFO neutron.openstack.common.rpc.common [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Connected to AMQP server on vip-rabbitmq:5672 2014-11-11 10:27:35.348 3027 INFO neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Agent initialized successfully, now running... 2014-11-11 10:27:35.351 3027 INFO neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Agent out of sync with plugin! 2014-11-11 10:27:35.401 3027 INFO neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Agent tunnel out of sync with plugin! 2014-11-11 10:27:35.414 3027 INFO neutron.openstack.common.rpc.common [req-66ba318b-0fcc-42c2-959e-9a5233c292ef None] Connected to AMQP server on vip-rabbitmq:5672 2014-11-11 10:32:33.143 3027 INFO neutron.agent.securitygroups_rpc [req-22c7fa11-882d-4278-9f83-6dd56ab95ba4 None] Security group member updated [u'4c7b3ad2-4526-48a7-959e-a8b8e4da6413'] 2014-11-11 10:58:11.916 3027 INFO neutron.agent.securitygroups_rpc [req-484fd71f-8f61-496c-aa8a-2d3abf8de365 None] Security group member updated [u'4c7b3ad2-4526-48a7-959e-a8b8e4da6413'] 2014-11-11 10:59:43.954 3027 INFO neutron.agent.securitygroups_rpc [req-2c0bc777-04ed-470a-aec5-927a59100b89 None] Security group member updated [u'4c7b3ad2-4526-48a7-959e-a8b8e4da6413'] 2014-11-11 11:00:22.500 3027 INFO neutron.agent.securitygroups_rpc [req-df447d01-d132-40f2-8528-1c1c4d57c0f5 None] Security group member updated [u'4c7b3ad2-4526-48a7-959e-a8b8e4da6413'] 2014-11-12 01:27:35.662 3027 ERROR neutron.openstack.common.rpc.common [-] Failed to consume message from queue: Socket closed 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common Traceback (most recent call last): 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/neutron/openstack/common/rpc/impl_kombu.py", line 579, in ensure 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common return method(*args, **kwargs) 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/neutron/openstack/common/rpc/impl_kombu.py", line 659, in _consume 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common return self.connection.drain_events(timeout=timeout) 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 281, in drain_events 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common return self.transport.drain_events(self.connection, **kwargs) 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 94, in drain_events 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common return connection.drain_events(**kwargs) 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 266, in drain_events 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common chanmap, None, timeout=timeout, 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 328, in _wait_multiple 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common channel, method_sig, args, content = read_timeout(timeout) 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 292, in read_timeout 2014-11-12 01:27:35.662 3027 TRACE neutron.openstack.common.rpc.common return self.method_reader.read_method() 2014-11-12 01:27:35.66
[Yahoo-eng-team] [Bug 1540873] [NEW] Error: Service n-xvnc is not running
Public bug reported: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. ** Affects: devstack Importance: Undecided Status: New ** Affects: neutron Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Affects: tempest Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New ** Also affects: tempest 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/1540873 Title: Error: Service n-xvnc is not running Status in devstack: New Status in neutron: New Status in OpenStack Compute (nova): New Status in tempest: New Bug description: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1540873/+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 1540873] Re: Error: Service n-xvnc is not running
** No longer affects: tempest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1540873 Title: Error: Service n-xvnc is not running Status in devstack: New Status in neutron: New Status in OpenStack Compute (nova): New Bug description: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1540873/+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 1540873] Re: Error: Service n-xvnc is not running
I suspect the problem appeared when the change was merged: https://review.openstack.org/#/c/235398/ This should fix it: https://review.openstack.org/#/c/274889/ ** No longer affects: 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/1540873 Title: Error: Service n-xvnc is not running Status in devstack: New Status in OpenStack Compute (nova): New Bug description: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1540873/+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 1540254] Re: "#flake8: noqa" is using incorrectly
Reviewed: https://review.openstack.org/274637 Committed: https://git.openstack.org/cgit/openstack/python-novaclient/commit/?id=0105fd120659baf3445b994af29837755d155c73 Submitter: Jenkins Branch:master commit 0105fd120659baf3445b994af29837755d155c73 Author: Bo Wang Date: Mon Feb 1 20:17:47 2016 +0800 Use # noqa to ignore one line but not whole file "# flake8: noqa" option disables all checks for the whole file. To disable one line we should use "# noqa". Closes Bug: #1540254 Change-Id: I34c8a2218f974cd7e78c60e9c1fec26751c4e82d ** Changed in: python-novaclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1540254 Title: "#flake8: noqa" is using incorrectly Status in OpenStack Dashboard (Horizon): In Progress Status in python-heatclient: Fix Released Status in python-novaclient: Fix Released Bug description: "# flake8: noqa" option disables all checks for the whole file. To disable one line we should use "# noqa". Refer to: https://pypi.python.org/pypi/flake8 https://github.com/openstack/python-keystoneclient/commit/3b766c51438396a0ab0032de309c9d56e275e0cb To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1540254/+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 1372564] Re: Incorrect status change after image uploading in v2
** Changed in: glance Status: Invalid => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1372564 Title: Incorrect status change after image uploading in v2 Status in Glance: In Progress Status in Glance juno series: Fix Released Status in Glance kilo series: Fix Released Bug description: If the image is deleted (i.e. its status changed to 'deleted' in db) when it's uploading through image-upload command in v2, its status surprisingly switches from 'deleted' to 'active' without any exception. There is the code that should handle NotFound exception in that case https://github.com/openstack/glance/blob/master/glance/api/v2/image_data.py :77 except exception.NotFound as e: msg = (_("Image %(id)s could not be found after upload." "The image may have been deleted during the upload: " "%(error)s Cleaning up the chunks uploaded") % {'id': image_id, 'error': utils.exception_to_str(e)}) but it never executes because the exception is not raised. In v1 this problem is solved with explicitly passing from_state argument, but in v2 it's not possible. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1372564/+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 1540873] Re: Error: Service n-xvnc is not running
https://review.openstack.org/#/c/274889/ was merged. ** Changed in: nova Status: New => 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/1540873 Title: Error: Service n-xvnc is not running Status in devstack: New Status in OpenStack Compute (nova): Fix Released Bug description: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1540873/+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 1540934] [NEW] glance-cache-prefetcher is broken
Public bug reported: Glance prefetcher is still configured to use keystone v1. As it still does not use the right uri or pass the values as json but rather uses headers. ** Affects: glance Importance: Undecided Assignee: Niall Bunting (niall-bunting) 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/1540934 Title: glance-cache-prefetcher is broken Status in Glance: New Bug description: Glance prefetcher is still configured to use keystone v1. As it still does not use the right uri or pass the values as json but rather uses headers. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1540934/+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 1540873] Re: Error: Service n-xvnc is not running
I tested, it fixed it. ** No longer affects: devstack -- 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/1540873 Title: Error: Service n-xvnc is not running Status in OpenStack Compute (nova): Fix Released Bug description: When stacking I am getting below error many times since a pair of days: 2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running' 2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running 2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']' 2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can be found with screen, with ./rejoin-stack.sh' 2016-02-02 11:07:08,278 | + local exitcode=0 2016-02-02 11:07:08,278 | [Call Trace] 2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check 2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die 2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 More details about the above errors can be found with screen, with ./rejoin-stack.sh 2016-02-02 11:07:08,279 | Error on exit This is new. I am not sure witch repository between devstack, nova and neutron introduced it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1540873/+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 1540939] [NEW] Instance delete causing port leak
Public bug reported: Nova can cause a neutron port leak after deleting an instance. If neutron has the port binding extension installed, then nova uses admin credentials to create the port during instance create: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L537 However, during instance delete, nova always uses the user creds: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L739 Depending on the neutron policy settings, this can leak ports in neutron. Can someone explain this behavior? We are running on nova kilo. ** 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/1540939 Title: Instance delete causing port leak Status in OpenStack Compute (nova): New Bug description: Nova can cause a neutron port leak after deleting an instance. If neutron has the port binding extension installed, then nova uses admin credentials to create the port during instance create: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L537 However, during instance delete, nova always uses the user creds: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L739 Depending on the neutron policy settings, this can leak ports in neutron. Can someone explain this behavior? We are running on nova kilo. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1540939/+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 1540960] [NEW] DHCP: when upgrading from icehouse DHCP breaks
Public bug reported: When upgrading the J, K or any other version the DNS support break. That is, the DHCP agent has the option for setting DNS servers, this is via the the options dnsmasq_config_file=/etc/neutron/myconfig.ini Where myconfig will have support for the following: dhcp-option=5,2.4.5.6,2.4.5.7 dhcp-option=6,2.4.5.7,2.4.5.6 In the guest /etc/resolve.conf we see the DHCP address and not the configured IP's The reason for this is https://github.com/openstack/neutron/commit/3686d035ded94eadab6a3268e4b0f0cca11a22f8 ** 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/1540960 Title: DHCP: when upgrading from icehouse DHCP breaks Status in neutron: New Bug description: When upgrading the J, K or any other version the DNS support break. That is, the DHCP agent has the option for setting DNS servers, this is via the the options dnsmasq_config_file=/etc/neutron/myconfig.ini Where myconfig will have support for the following: dhcp-option=5,2.4.5.6,2.4.5.7 dhcp-option=6,2.4.5.7,2.4.5.6 In the guest /etc/resolve.conf we see the DHCP address and not the configured IP's The reason for this is https://github.com/openstack/neutron/commit/3686d035ded94eadab6a3268e4b0f0cca11a22f8 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540960/+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 1540748] Re: ml2: port_update and port_delete should not use faout notify
** 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/1540748 Title: ml2: port_update and port_delete should not use faout notify Status in neutron: Invalid Bug description: Now for ml2 plugin, neutron-server use faout RPC message for port_update and port_delete, the codes as below: def port_update(self, context, port, network_type, segmentation_id, physical_network): cctxt = self.client.prepare(topic=self.topic_port_update,fanout=True) cctxt.cast(context, 'port_update', port=port, network_type=network_type, segmentation_id=segmentation_id, physical_network=physical_network) def port_delete(self, context, port_id): cctxt = self.client.prepare(topic=self.topic_port_delete, fanout=True) cctxt.cast(context, 'port_delete', port_id=port_id) I think neutron-server should directly sends the RPC message to port's binding_host, this can offload work for AMQP To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540748/+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 1387055] Re: glanceclient/shell.py:592: raise exc.CommandError("Invalid OpenStack Identity credentials.")
Closing due to inactivity. Latest devstack has been installed successfully. ** Changed in: glance Status: New => Won't Fix ** Changed in: python-glanceclient Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1387055 Title: glanceclient/shell.py:592:raise exc.CommandError("Invalid OpenStack Identity credentials.") Status in devstack: New Status in Glance: Won't Fix Status in python-glanceclient: Won't Fix Bug description: When using DevStack to install OpenStack, I got the following error: 2014-10-29 15:06:45.890 | ++ glance --os-auth-token 12a7b1359dc044ff9e9e1c81a2390152 --os-image-url http://192.168.56.101:9292 image-create --name cirros-0.3.1-x86_64-uec-kernel --is-public True --container-format aki --disk-format aki 2014-10-29 15:06:45.915 | ++ read data 2014-10-29 15:06:50.456 | Invalid OpenStack Identity credentials. 2014-10-29 15:06:50.584 | + KERNEL_ID= 2014-10-29 15:06:50.640 | + '[' -n /home/xtrutri/Work/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd ']' 2014-10-29 15:06:50.657 | ++ glance --os-auth-token 12a7b1359dc044ff9e9e1c81a2390152 --os-image-url http://192.168.56.101:9292 image-create --name cirros-0.3.1-x86_64-uec-ramdisk --is-public True --container-format ari --disk-format ari 2014-10-29 15:06:50.681 | ++ grep ' id ' 2014-10-29 15:06:50.690 | ++ get_field 2 2014-10-29 15:06:50.699 | ++ read data 2014-10-29 15:06:55.658 | Invalid OpenStack Identity credentials. 2014-10-29 15:06:55.733 | + RAMDISK_ID= 2014-10-29 15:06:55.783 | + glance --os-auth-token 12a7b1359dc044ff9e9e1c81a2390152 --os-image-url http://192.168.56.101:9292 image-create --name cirros-0.3.1-x86_64-uec --is-public True --container-format ami --disk-format ami 2014-10-29 15:07:00.966 | Invalid OpenStack Identity credentials. xtrutri@ubuntu:~/Work/devstack$ 2014-10-29 15:07:01.061 | + exit_trap DevStack version: at commit 8cedabcea8bb446f1c29aab42fbcbf5a87218f7f (Sat May 10 12:24:16 2014 +) KeyStone version: 2014.2.rc1-106-gf45b3e5 GlanceClient version: 0.14.1-11-gcfe0623 Glance version: 2014.2.rc1-91-gded0852 Here is the traceback: 2014-10-29 15:06:57.263 16394 DEBUG glance.api.middleware.version_negotiation [-] Using url versioning process_request /opt/stack_stable_juno/glance/glance/api/middleware/version_negotiation.py:57 2014-10-29 15:06:57.265 16394 DEBUG glance.api.middleware.version_negotiation [-] Matched version: v1 process_request /opt/stack_stable_juno/glance/glance/api/middleware/version_negotiation.py:69 2014-10-29 15:06:57.266 16394 DEBUG glance.api.middleware.version_negotiation [-] new path /v1/images process_request /opt/stack_stable_juno/glance/glance/api/middleware/version_negotiation.py:70 2014-10-29 15:06:57.267 16394 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://127.0.0.1:35357/ -H "Accept: application/json" -H "User-Agent: python-keystoneclient" _http_log_request /opt/stack_stable_juno/python-keystoneclient/keystoneclient/session.py:162 2014-10-29 15:06:57.270 16394 WARNING keystonemiddleware.auth_token [-] Retrying on HTTP connection exception: Unable to establish connection to http://127.0.0.1:35357/ 2014-10-29 15:06:57.772 16394 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://127.0.0.1:35357/ -H "Accept: application/json" -H "User-Agent: python-keystoneclient" _http_log_request /opt/stack_stable_juno/python-keystoneclient/keystoneclient/session.py:162 2014-10-29 15:06:57.775 16394 WARNING keystonemiddleware.auth_token [-] Retrying on HTTP connection exception: Unable to establish connection to http://127.0.0.1:35357/ 2014-10-29 15:06:58.777 16394 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://127.0.0.1:35357/ -H "Accept: application/json" -H "User-Agent: python-keystoneclient" _http_log_request /opt/stack_stable_juno/python-keystoneclient/keystoneclient/session.py:162 2014-10-29 15:06:58.782 16394 WARNING keystonemiddleware.auth_token [-] Retrying on HTTP connection exception: Unable to establish connection to http://127.0.0.1:35357/ 2014-10-29 15:07:00.793 16394 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://127.0.0.1:35357/ -H "Accept: application/json" -H "User-Agent: python-keystoneclient" _http_log_request /opt/stack_stable_juno/python-keystoneclient/keystoneclient/session.py:162 2014-10-29 15:07:00.803 16394 ERROR keystonemiddleware.auth_token [-] HTTP connection exception: Unable to establish connection to http://127.0.0.1:35357/ 2014-10-29 15:07:00.807 16394 WARNING keystonemiddleware.auth_token [-] Authorization failed for token To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1387055/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.laun
[Yahoo-eng-team] [Bug 1540983] [NEW] Gate failures for neutron in test_dualnet_multi_prefix_slaac
Public bug reported: 24 hits in 7 days for logstash query : message:"in test_dualnet_multi_prefix_slaac" AND voting:1 2016-02-02 14:35:49.054 | Captured traceback: 2016-02-02 14:35:49.054 | ~~~ 2016-02-02 14:35:49.054 | Traceback (most recent call last): 2016-02-02 14:35:49.054 | File "tempest/test.py", line 113, in wrapper 2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 246, in test_dualnet_multi_prefix_slaac 2016-02-02 14:35:49.055 | dualnet=True) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 155, in _prepare_and_test 2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = self.prepare_server(networks=net_list) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 128, in prepare_server 2016-02-02 14:35:49.055 | username=username) 2016-02-02 14:35:49.056 | File "tempest/scenario/manager.py", line 390, in get_remote_client 2016-02-02 14:35:49.056 | linux_client.validate_authentication() 2016-02-02 14:35:49.056 | File "tempest/common/utils/linux/remote_client.py", line 63, in validate_authentication 2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 172, in test_connection_auth 2016-02-02 14:35:49.056 | connection = self._get_ssh_connection() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 87, in _get_ssh_connection 2016-02-02 14:35:49.057 | password=self.password) 2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection to the 172.24.5.141 via SSH timed out. 2016-02-02 14:35:49.057 | User: cirros, Password: None ** Affects: neutron Importance: Undecided Status: New ** Affects: openstack-gate Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1540983 Title: Gate failures for neutron in test_dualnet_multi_prefix_slaac Status in neutron: New Status in OpenStack-Gate: New Bug description: 24 hits in 7 days for logstash query : message:"in test_dualnet_multi_prefix_slaac" AND voting:1 2016-02-02 14:35:49.054 | Captured traceback: 2016-02-02 14:35:49.054 | ~~~ 2016-02-02 14:35:49.054 | Traceback (most recent call last): 2016-02-02 14:35:49.054 | File "tempest/test.py", line 113, in wrapper 2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 246, in test_dualnet_multi_prefix_slaac 2016-02-02 14:35:49.055 | dualnet=True) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 155, in _prepare_and_test 2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = self.prepare_server(networks=net_list) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 128, in prepare_server 2016-02-02 14:35:49.055 | username=username) 2016-02-02 14:35:49.056 | File "tempest/scenario/manager.py", line 390, in get_remote_client 2016-02-02 14:35:49.056 | linux_client.validate_authentication() 2016-02-02 14:35:49.056 | File "tempest/common/utils/linux/remote_client.py", line 63, in validate_authentication 2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 172, in test_connection_auth 2016-02-02 14:35:49.056 | connection = self._get_ssh_connection() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 87, in _get_ssh_connection 2016-02-02 14:35:49.057 | password=self.password) 2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection to the 172.24.5.141 via SSH timed out. 2016-02-02 14:35:49.057 | User: cirros, Password: None To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540983/+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 1517839] Re: Make CONF.set_override with parameter enforce_type=True by default
** Changed in: watcher Status: New => 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/1517839 Title: Make CONF.set_override with parameter enforce_type=True by default Status in Ceilometer: New Status in cloudkitty: New Status in Designate: Confirmed Status in Gnocchi: In Progress Status in heat: New Status in OpenStack Identity (keystone): Fix Released Status in Manila: New Status in Murano: In Progress Status in neutron: In Progress Status in oslo.config: New Status in oslo.messaging: Fix Released Status in Rally: Fix Released Status in watcher: Fix Released Bug description: 1. Problems : oslo_config provides method CONF.set_override[1] , developers usually use it to change config option's value in tests. That's convenient . By default parameter enforce_type=False, it doesn't check any type or value of override. If set enforce_type=True , will check parameter override's type and value. In production code(running time code), oslo_config always checks config option's value. In short, we test and run code in different ways. so there's gap: config option with wrong type or invalid value can pass tests when parameter enforce_type = False in consuming projects. that means some invalid or wrong tests are in our code base. There is nova POC result when I enable "enforce_type=true" [2], and I must fix them in [3] [1] https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173 [2] http://logs.openstack.org/16/242416/1/check/gate-nova-python27/97b5eff/testr_results.html.gz [3] https://review.openstack.org/#/c/242416/ https://review.openstack.org/#/c/242717/ https://review.openstack.org/#/c/243061/ 2. Proposal 1) Make method CONF.set_override with enforce_type=True in consuming projects. and fix violations when enforce_type=True in each project. 2) Make method CONF.set_override with enforce_type=True by default in oslo_config Hope some one from consuming projects can help make enforce_type=True in consuming projects and fix violations, You can find more details and comments in https://etherpad.openstack.org/p/enforce_type_true_by_default To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1517839/+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 1538197] Re: booting from volume throws http 500 if volume size is not specified
Reviewed: https://review.openstack.org/272732 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5cad74c27befb8f1bd584753de21d8ca60eaf901 Submitter: Jenkins Branch:master commit 5cad74c27befb8f1bd584753de21d8ca60eaf901 Author: Balazs Gibizer Date: Tue Jan 26 21:48:11 2016 +0100 Return HTTP 400 if volume size is not defined Nova API properly checks that in case of booting from a image to volume bdm the client shall specify the size of the created volume. However the API does not handle the exception properly and returns HTTP 500. This patch handles the InvalidBDM exception and returns HTTP 400. Change-Id: I80d0aa64885f25081dad91b1f45da5b318d8ae25 Closes-bug: #1538197 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1538197 Title: booting from volume throws http 500 if volume size is not specified Status in OpenStack Compute (nova): Fix Released Bug description: If a instance is booted from volume with an image to volume bdm where the volume size is not specified nova throws http 500 instead of http 400. Visible on master (b558d616c3b123dbe2a0914162b45765192f3a12) with devstack. To reproduce: $ nova image-list +--+-+++ | ID | Name| Status | Server | +--+-+++ | a7e6b974-0b5a-4d60-8d68-d4745aae9bb3 | cirros-0.3.4-x86_64-uec | ACTIVE || | 10672d57-30b3-4c41-9f5b-f42c030970fa | cirros-0.3.4-x86_64-uec-kernel | ACTIVE || | 70790401-6760-48d5-9bf4-175d18cfc9d6 | cirros-0.3.4-x86_64-uec-ramdisk | ACTIVE || +--+-+++ $ nova boot --flavor 42 --block-device source=image,id=a7e6b974-0b5a-4d60-8d68-d4745aae9bb3,dest=volume,shutdown=preserve,bootindex=0 --poll vm1 ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-996d695a-3f36-48ee-b91f-567c3ab2f1ce) There is a stack trace in the nova-api log: 2016-01-20 18:51:58.400 ERROR nova.api.openstack.extensions [req-996d695a-3f36-48ee-b91f-567c3ab2f1ce admin admin] Unexpected exception in API method 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions return f(*args, **kwargs) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/compute/servers.py", line 604, in create 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions **create_kwargs) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/hooks.py", line 149, in inner 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions rv = f(*args, **kwargs) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/api.py", line 1504, in create 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions check_server_group_quota=check_server_group_quota) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/api.py", line 1127, in _create_instance 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions instance_group, check_server_group_quota) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/api.py", line 976, in _provision_instances 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions quotas.rollback() 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204, in __exit__ 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions six.reraise(self.type_, self.value, self.tb) 2016-01-20 18:51:58.400 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/a
[Yahoo-eng-team] [Bug 1508442] Re: LOG.warn is deprecated
** Changed in: keystone 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/1508442 Title: LOG.warn is deprecated Status in anvil: In Progress Status in Aodh: In Progress Status in Astara: Fix Released Status in Barbican: In Progress Status in bilean: In Progress Status in Blazar: In Progress Status in Ceilometer: Fix Released Status in cloud-init: In Progress Status in cloudkitty: Fix Released Status in congress: In Progress Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in django-openstack-auth-kerberos: New Status in DragonFlow: Fix Released Status in ec2-api: In Progress Status in Evoque: In Progress Status in gce-api: In Progress Status in Glance: In Progress Status in glance_store: In Progress Status in Gnocchi: In Progress Status in heat: Fix Released Status in heat-cfntools: In Progress Status in OpenStack Identity (keystone): Fix Released Status in KloudBuster: Fix Released Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: In Progress Status in networking-arista: In Progress Status in networking-calico: In Progress Status in networking-cisco: In Progress Status in networking-fujitsu: In Progress Status in networking-odl: In Progress Status in networking-ofagent: In Progress Status in networking-plumgrid: In Progress Status in networking-powervm: In Progress Status in networking-vsphere: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: In Progress Status in openstack-ansible: In Progress Status in oslo.cache: Fix Released Status in oslo.privsep: In Progress Status in Packstack: Fix Released Status in python-dracclient: In Progress Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: In Progress Status in shaker: In Progress Status in Solum: Fix Released Status in tempest: In Progress Status in tripleo: In Progress Status in trove-dashboard: In Progress Status in watcher: Fix Released Status in zaqar: In Progress Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 1534625] Re: [Pluggable IPAM] Ipam driver is not called on update subnet if allocation pools are blank
** Also affects: networking-infoblox Importance: Undecided Status: New ** Changed in: networking-infoblox Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1534625 Title: [Pluggable IPAM] Ipam driver is not called on update subnet if allocation pools are blank Status in networking-infoblox: New Status in neutron: In Progress Bug description: Currently ipam driver is called on subnet_update only if allocation_pools set in subnet dict. See [1]. This happens because original design expectation is that the only information ipam driver has to update is allocation pools. For reference ipam driver that is absolutely correct. But 3rd party ipam vendors might want to utilize this call to keep track of other fields updates in subnet. So my suggestion here is to call update_subnet in ipam_driver on each subnet update and let ipam driver decide if it has to do some processing or not. In Infoblox we need it to keep track of dns_nameservers on subnet_update. Currently we can obtain this dns_nameservers info on subnet update only if allocation_pools present in subnet_update request. Is it a bug from neutron perspective? [1] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_pluggable_backend.py#L356 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-infoblox/+bug/1534625/+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 1454968] Re: hard to understand the uri printed in the log
** Changed in: keystone/juno Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1454968 Title: hard to understand the uri printed in the log Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Won't Fix Status in OpenStack Identity (keystone) kilo series: Fix Released Bug description: In keystone's log file, we can easily find some uri printed like this: http://127.0.0.1:35357/v3/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens seems there is something wrong when we are trying to log the uri in the log file. LOG.info('%(req_method)s %(uri)s', { 'req_method': req.environ['REQUEST_METHOD'].upper(), 'uri': wsgiref.util.request_uri(req.environ), }) code is here: https://github.com/openstack/keystone/blob/0debc2fbf448b44574da6f3fef7d457037c59072/keystone/common/wsgi.py#L232 but seems it has already been wrong when the req is passed in. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1454968/+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 1385643] Re: /auth/domains incorrectly includes domains with only group inherited roles
** Changed in: keystone/juno Status: Fix Committed => Fix Released -- 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/1385643 Title: /auth/domains incorrectly includes domains with only group inherited roles Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Released Bug description: The /auth/domains API call is meant to return list of domains for which the user could ask for a domain-scoped token - i.e. any domain on which they have a role. However, the code does not differentiate between inherited and non-inherited group roles - and hence might include domains for which the user has no effective role (a domain inherited role ONLY applies to the projects within that domain, not to the domain itself). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1385643/+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 1483419] Re: Single Domain to Multi Domain assignments are lost
this expired months ago, but didn't because it was attached to an assignee ** Changed in: keystone Status: Incomplete => Won't Fix ** Changed in: keystone Assignee: Henry Nash (henry-nash) => (unassigned) ** Changed in: keystone Milestone: mitaka-3 => None ** Changed in: keystone Importance: High => Undecided -- 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/1483419 Title: Single Domain to Multi Domain assignments are lost Status in OpenStack Identity (keystone): Won't Fix Bug description: When upgrading from a single domain LDAP environment to a multi domain LDAP environment all user role assignments are lost. The assignments' field actor_id is mapped to a user name in a single domain setup. When setting 'domain_specific_drivers_enabled=true' the actor_id field now maps to a new UUID which results in all existing users, including service users, losing their role assignments. I was able to overcome this rather forcefully with this SQL query: INSERT IGNORE INTO assignment(actor_id, target_id, role_id) SELECT id_mapping.public_id, assignment.target_id, assignment.role_id FROM id_mapping INNER JOIN assignment on id_mapping.local_id = assignment.actor_id; Version Tested: 2014.2.4 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483419/+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 1385694] Re: /auth/projects fails to include any projects that have inherited group roles
** Changed in: keystone/juno Status: Fix Committed => Fix Released -- 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/1385694 Title: /auth/projects fails to include any projects that have inherited group roles Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Released Bug description: The /auth/projects API call is meant to return list of projects for which the user could ask for a project-scoped token - i.e. any project on which they have a role. However, the code does not look at any roles that a group may have on a domain that are marked as inherited to projects - hence failing to include these projects in the list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1385694/+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 1395959] Re: assignment table migration fails for keystone-manage db_sync if duplicate entry exists
** Changed in: keystone/juno Status: New => Won't Fix -- 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/1395959 Title: assignment table migration fails for keystone-manage db_sync if duplicate entry exists Status in OpenStack Identity (keystone): Invalid Status in OpenStack Identity (keystone) juno series: Won't Fix Bug description: When moving from Havana to Icehouse (Keystone version 38 -> 44) and keystone-manage db_sync runs, it fails if there are duplicate project entries. 2014-11-24 23:12:58.701 9239 CRITICAL keystone [-] IntegrityError: (IntegrityError) (1062, "Duplicate entry 'UserProject- 096cb95691404a959289200afa7d4b2f-c0036d48a8524cf6ba1' for key 'PRIMARY'") 'INSERT INTO assignment (type, actor_id, target_id, role_id, inherited) VALUES (%s, %s, %s, %s, %s)' ('UserProject', '096cb95691404a959289200afa7d4b2f', 'c0036d48a8524cf6ba1ed6e857649989', '9fe2ff9ee4384b1894a90878d3e92bab', False) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1395959/+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 1524124] Re: unscalable database schema design
** Changed in: keystone Status: New => Opinion -- 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/1524124 Title: unscalable database schema design Status in OpenStack Identity (keystone): Opinion Bug description: I have noticed the keystone SQL database schema design is not scalable. It can hold maybe a few hundreds or maximum thousands of entries, but beyond this, it is going to certainly create very serious efficiency problems, both in terms storage space and query response time. Here are the main problem points I have spotted: i) most of the tables use primary keys of varchar(64) type: role, domain, project, token, user, group etc., supposed to contain unique hex identifiers. I am not exactly sure about the rationale behind this design? If the idea is to be able to accommodate up to 16**64=10**77 distinct records, than this is clearly flawed, as the tables won't hold more than a few thousand entries given the current length of the primary key (and foreign keys, for those minor entity tables that refer to the major entity). ii) some tables have composite keys on multiple varchar(64) fields: Create Table: CREATE TABLE `assignment` ( `type` enum('UserProject','GroupProject','UserDomain','GroupDomain') NOT NULL, `actor_id` varchar(64) NOT NULL, `target_id` varchar(64) NOT NULL, `role_id` varchar(64) NOT NULL, `inherited` tinyint(1) NOT NULL, PRIMARY KEY (`type`,`actor_id`,`target_id`,`role_id`), KEY `ix_actor_id` (`actor_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.00 sec) iii) some tables have unique keys defined on varchar(255) columns: Create Table: CREATE TABLE `role` ( `id` varchar(64) NOT NULL, `name` varchar(255) NOT NULL, `extra` text, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 iv) the generated public id for (user,domain) entities is currently 64 hex chars, while only 32 hex chars are needed to ensure uniqueness up to 16**16=2**64=10**19 entries, which should be more than sufficient for any practical installation. In order to remedy these problems, I propose the following improvements: i) replace the varchar(64) hex primary key by an auto-incremented integer(4) column. This will hold up to 4 billion records and will greatly reduce the storage requirements and improve query performance. ii) reduce the generated public id for (user, domain) entities to 32 hex chars, stored in binary form as two bigint(8) columns. iii) reduce the "name" field length to more manageable length or reduce index size using a hash function. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1524124/+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 1533079] Re: Removal of EC2 code
EC2 handling is still enabled in keystone and there is work to make EC2 external to nova. ** Changed in: keystone Status: New => Won't Fix -- 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/1533079 Title: Removal of EC2 code Status in OpenStack Identity (keystone): Won't Fix Bug description: Some time ago the EC2 code inside Nova was deprecated and will be removed during Mitaka. With https://review.openstack.org/#/c/226856/ the EC2 API is not longer enabled by default. Because the EC2 API is not longer enabled by default I think we have to remove the EC2 service/user from the tools/sample_data.sh script, the endpoint from the etc/default_catalog.templates file, the EC2 service from the doc/source/configuringservices.rst documentation file. I am not sure about keystone.contrib.ec2. Also I am not sure about EC2 specifc test cases in keystone.tests. Are they required by the new ec2-api project? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1533079/+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 1433194] Re: Max header length not configurable for eventlet
PKI Tokens are Deprecated and therefore this is really a non-issue going forward. ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1433194 Title: Max header length not configurable for eventlet Status in OpenStack Identity (keystone): Won't Fix Bug description: In nova.conf and other services config file it is possible to set max_header_line=32768 to handle large keystone v3 token. But for keystone, you can not define it in keystone.conf, it is only hardcoded in the source (keystone/common/environment/__init__.py) to 16k Our deployment have 2 regions, the resulting keystone v3 token are more bigger 16k. Setting the max_header_line in the configuration file would be a huge improvement. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1433194/+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 1287414] Re: Keystone should not require CA key
PKI Tokens are Deprecated - this was in support of pki tokens. ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1287414 Title: Keystone should not require CA key Status in OpenStack Identity (keystone): Won't Fix Bug description: Why do we need CA key? In a real deployment I were to get a cert for my server from Verisign, then verisign won't provide its key. Basically the code should work without CA key. I believe it is not required for ssl setup and signing. [ssl] #enable = True #certfile = /etc/keystone/ssl/certs/keystone.pem #keyfile = /etc/keystone/ssl/private/keystonekey.pem #ca_certs = /etc/keystone/ssl/certs/ca.pem #ca_key = /etc/keystone/ssl/private/cakey.pem #key_size = 1024 #valid_days = 3650 #cert_required = False #cert_subject = /C=US/ST=Unset/L=Unset/O=Unset/CN=localhost [signing] # Deprecated in favor of provider in the [token] section # Allowed values are PKI or UUID #token_format = #certfile = /etc/keystone/ssl/certs/signing_cert.pem #keyfile = /etc/keystone/ssl/private/signing_key.pem #ca_certs = /etc/keystone/ssl/certs/ca.pem #ca_key = /etc/keystone/ssl/private/cakey.pem #key_size = 2048 #valid_days = 3650 #cert_subject = /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1287414/+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 1317302] Re: pki_setup shouldn't be required to check revocations
PKI Tokens are Deprecated ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1317302 Title: pki_setup shouldn't be required to check revocations Status in OpenStack Identity (keystone): Won't Fix Status in keystonemiddleware: In Progress Bug description: With the fix for bug 1312858 , auth_token can validate UUID tokens or hashed PKI tokens against the revocation list. But in order to use this in a setting where only UUID tokens are being used, the server still needs to have pki_setup run. We should be able to check UUID tokens against the revocation list even when pki_setup hasn't been done. The reason pki_setup has to be done is that the revocation list is signed using CMS. The auth_token middleware only accepts the signed format for the revocation list. The proposed solution is to change the auth_token middleware to also accept a revocation list that's not signed. If it's not signed, then the PKI certificates aren't required. The keystone server will be changed to allow configuring it such that the revocation list will be sent as an unencrypted JSON object that the auth_token middleware can now accept. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317302/+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 1198183] Re: replacement of calls to "openssl" with calls to pyOpenSSL
PKI Tokens are Deprecated and this is not needed. ** Changed in: keystone Status: Confirmed => Won't Fix -- 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/1198183 Title: replacement of calls to "openssl" with calls to pyOpenSSL Status in OpenStack Identity (keystone): Won't Fix Bug description: There are some calls to "openssl" (for example in keystone/common/openssl.py and keystone/common/cms.py). I would prefer it to use pyOpenSSL instead of calling external 3rd party apps without an absolute path. Are there any rationales for using "openssl" instead of pyOpenSSL? If not I would try to replace all "openssl" calls with calls to pyOpenSSL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1198183/+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 1205153] Re: Unable to have multiple signing certs for PKI tokens
PKI Tokens are Deprecated ** Changed in: keystone Status: Confirmed => Won't Fix -- 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/1205153 Title: Unable to have multiple signing certs for PKI tokens Status in OpenStack Identity (keystone): Won't Fix Bug description: Right now Keystone assumes a single signing certificate. In order to support multiple, we need to be able to identify which certificate to use in order to verify the token. Although the CMS based tokens have a Serial number embedded, to parse this information out would take an additional call to Popen the openssl binary. Instead, we should put a certificate identifier into the token itself that van be parsed out via simple string parsing. An example would be CMS:41123:MII... CMS is just to identify token format. 41123 is the identifier. MII is the signed token as currently produced. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1205153/+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 1362343] Re: weak digest algorithm for PKI
PKI Tokens are Deprecated ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (keystone): Won't Fix Status in python-keystoneclient: Fix Released Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+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 1541092] [NEW] squash migrations in preparation for mitaka
Public bug reported: squash everything that was included in kilo: rename 067_drop_redundant_mysql_index.py to 067_kilo.py and delete the others ** Affects: keystone Importance: High Status: Confirmed ** Changed in: keystone Status: New => Confirmed ** Changed in: keystone Importance: Undecided => High ** Changed in: keystone Milestone: None => mitaka-3 -- 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/1541092 Title: squash migrations in preparation for mitaka Status in OpenStack Identity (keystone): Confirmed Bug description: squash everything that was included in kilo: rename 067_drop_redundant_mysql_index.py to 067_kilo.py and delete the others To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1541092/+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 1541090] [NEW] Integration password config should match local_conf
Public bug reported: In our recommended local_conf.rst, we use pass for password. The password in our integration tests should reflect this as well. Link to local_conf.rst https://github.com/openstack/horizon/blob/master/doc/source/ref/local_conf.rst ** Affects: horizon Importance: Low Assignee: Thai Tran (tqtran) Status: In Progress ** Tags: documentation -- 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/1541090 Title: Integration password config should match local_conf Status in OpenStack Dashboard (Horizon): In Progress Bug description: In our recommended local_conf.rst, we use pass for password. The password in our integration tests should reflect this as well. Link to local_conf.rst https://github.com/openstack/horizon/blob/master/doc/source/ref/local_conf.rst To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1541090/+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 1379077] Re: Tenants can be created with invalid ids
With V2 slowly disappearing, i am marking this as Wont Fix. ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1379077 Title: Tenants can be created with invalid ids Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Identity (keystone) icehouse series: Won't Fix Status in OpenStack Identity (keystone) juno series: Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: When creating a new tenant, there is an optional argument 'id' that may be passed: https://github.com/openstack/keystone/blob/9025b64a8f2bf5cf01a18453d6728e081bd2c3b9/keystone/assignment/controllers.py#L114 If not passed, this just creates a uuid and proceeds. If a value is passed, it will use that value. So a user with priv's to create a tenant can pass something like "../../../../../" as the id. If this is done, then the project can't be deleted without manually removing the value from the database. This can lead to a DoS that could fill the db and take down the cloud, in the worst of circumstances. I believe the proper fix here would be to just remove this feature altogether. But this is because I'm not clear about why we would ever want to allow someone to set the id manually. If there's a valid use case here, then we should at least do some input validation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1379077/+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 1177777] Re: Only MII tokens get properly hashed
PKI Tokens are deprecated. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/117 Title: Only MII tokens get properly hashed Status in OpenStack Identity (keystone): Won't Fix Bug description: There is nothing in the token API that implies tokens must be of the forms presented. For online verification, tokens can be anything, provided an appropriate plugin was created for Keystone. However, the current logic explicitly checks for 'MII' and, if that is missing, does not attempt to hash the Token. Thus, other format tokens will not be stored in the back end. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/117/+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 965502] Re: lack of service endpoint filtering for token validation can be a security vulnerability
It is not a security vulnerability. ** Changed in: keystone Status: Triaged => 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/965502 Title: lack of service endpoint filtering for token validation can be a security vulnerability Status in OpenStack Identity (keystone): Invalid Bug description: There was a bug logged against Keystone Essex 3 for the potential security issue with service role conflicts. https://bugs.launchpad.net/keystone/+bug/890411 Similarly, the lack of service endpoint ID filtering could also be a security issue. A service can have multiple endpoints (i.e. one in each geographic location). However, user may only allow to access a subset of the service endpoints based on authorization policy. Currently, there's no way to filter service endpoints during token validation. The following example illustrates the problem: 1) user activates Compute in AZ1 for tenantId XYZ 2) user calls Compute endpoint in AZ2 passing tenantId XYZ in the URL 3) Nova will allow #2 because it currently only authenticates at the 'tenant' level and not down to the service endpoint To mitigate this problem, we need to introduce optional service endpoint filtering capability for token validation and EC2 signature validation, much the same way as service ID filtering in bug 890411. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/965502/+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 1157261] Re: Performance issue on high concurrency
This bug isn't very useful. Targeted bugs for specific performance increases would be better. Marking this as "Invalid" please open bugs that are targeted not "general performance is poor" ** Changed in: keystone Status: Triaged => 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/1157261 Title: Performance issue on high concurrency Status in OpenStack Identity (keystone): Invalid Status in Mirantis OpenStack: Invalid Status in Mirantis OpenStack 6.0.x series: Invalid Status in Mirantis OpenStack 6.1.x series: Invalid Bug description: Im currently using Keystone as the auth-server in Swift. We have done performance test on our solution and we found that performance of keystone+swift is quite low, only 200 ops/s. While with the same setup the throughput can be improved to 7k ops/s by replacing keystone with swauth We found the keystone process is fully saturating one sandy bridge core. This looks like a scalability issue. Would be good if keystone could scale up well on a multi-core server. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1157261/+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 1172052] Re: /v2.0/certificates/* content is available even when token_format=UUID
PKI Tokens are deprecated, this extension likewise has been deprecated. Marking wont fix. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1172052 Title: /v2.0/certificates/* content is available even when token_format=UUID Status in OpenStack Identity (keystone): Won't Fix Bug description: When I set the "token_format = UUID" in the Keystone configuration file, I can still access certificates located on disk via the REST API, despite the fact that they are not used for token signing. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172052/+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 1541094] [NEW] Volume list does not work if User does not have right to list transfers
Public bug reported: If a User does not have the rights to list transfers and does has the right to list volumes when you go to the Project Compute Volume dashboard no volumes will be listed. The code in horizon/openstack_dashboard/api/cinder.py method volume_list_paged checks each volume transfer status and the method throw and exception and no volume will be listed. ** 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/1541094 Title: Volume list does not work if User does not have right to list transfers Status in OpenStack Dashboard (Horizon): New Bug description: If a User does not have the rights to list transfers and does has the right to list volumes when you go to the Project Compute Volume dashboard no volumes will be listed. The code in horizon/openstack_dashboard/api/cinder.py method volume_list_paged checks each volume transfer status and the method throw and exception and no volume will be listed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1541094/+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 1149604] Re: change password should require specific authorization
This is not doable as it would be a change of behavior. Marking as Wont Fix. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1149604 Title: change password should require specific authorization Status in OpenStack Identity (keystone): Won't Fix Bug description: In V3, in order to change the password, a user should only be allowed to provide an unscoped token In V2, we allow scoped, so we will continue to allow that. However, passing in a trust token will be specificially restricted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1149604/+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 1144427] Re: policy provide access to the response
This has already been implemented with the callbacks in the @protected decoreator. Marking as now invalid. ** Changed in: keystone Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1144427 Title: policy provide access to the response Status in OpenStack Identity (keystone): Invalid Bug description: Many of the API calls do not have enough information from the request to determine if the user should get access to the response data. For example, IN Keystone, when performing the operation GET /trusts/{trust_id}, it is only once the trust has been fetched from the Data base that we know if a user is the trustor or trustee. The policy interface needs to be able to optionally filter on the response values as opposed to just the request values. It also needs to be able to specify whether a denied response should return a 401 or a 404 for a denied resource. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1144427/+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 1214147] Re: non standard certificate subject string format
with PKI tokens deprecated and evenlet going away and pkisetup being removed this is no longer even a wishlist. marking as wont fix. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1214147 Title: non standard certificate subject string format Status in OpenStack Identity (keystone): Won't Fix Bug description: The keystone configuration * keystone/common/config.py * etc/keystone.conf.sample as well as the documentation * doc/source/configuration.rst all make reference to certificate subjects. A certificate subject is actually a DN (Distinguished Name). DN's are used in other places in X509 besides the subject (e.g. the issuer field and some certificate extensions use DN's). Although the string representation of a DN has long been standardized in RFC's (most recently in RFC-4514 superseding RFC-2253) OpenSSL cannot not accept RFC compliant DN's as input and will not output RFC compliant DN's by default. Of the major crypto implementations (OpenSSL, NSS, GnuTLS, Java BouncyCastle) it is only OpenSSL which fails to utilize RFC compliant DN's. OpenSSL's DN format is proprietary and unique to OpenSSL. OpenSSL cannot accept RFC compliant DN's and all the other libraries cannot accept OpenSSL's DN format. OpenStack should follow the relevant RFC's. The fact OpenSSL's pecular DN format was introduced into the generic configuration for Keystone is unfortunate. The following steps should be taken. 1. A conversion utility provided which converts between OpenSSL format and RFC format. This utility must handle multivalued RDN's and OID type names. 2. The configuration files and documentation must be modified to use RFC format. 3. The internal code must examine the cert subject (or any other DN) and determine what format it's it. If it's in OpenSSL format it should emit a deprecation warning. If it's in RFC format it should convert it to OpenSSL format before being passed to OpenSSL. Other crypto providers may need to convert a deprecated OpenSSL format into RFC format. Patches for this work are available. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1214147/+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 1173065] Re: RFE: Missing parameter --sql_connection for keystone-manage
looks like only the glance project supports this ** Changed in: keystone Status: Confirmed => Won't Fix -- 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/1173065 Title: RFE: Missing parameter --sql_connection for keystone-manage Status in OpenStack Identity (keystone): Won't Fix Bug description: Command keystone-manage is missing --sql_connection parameter as (cinder|glance)-manage has. This is useful when you need to "db_sync", but you don't want to modify config file. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1173065/+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 1291465] Re: Allow user-defined IDs
Keystone is very picky about maintaining the IDs of it's resources where it can. This is not in line with the general view of Keystone and the direction of the project. If anything we should be more picky. ** Changed in: keystone Status: Triaged => Opinion -- 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/1291465 Title: Allow user-defined IDs Status in OpenStack Identity (keystone): Opinion Bug description: This is a feature request We should alow user supplied domain_id/user_id. There are some policy defintions in policy.v2.cloudadmin.json which relies on user being on particular domain. We really don't want to have UUID in policy files to identify the domain_id. One way to achive this to bootstrap the entries via raw sql. It will be better if we allow the same to be achieved via REST api. So basically the ids' are given by the caller, If the caller doesn't send the id then generate UUID To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291465/+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 1218682] Re: User's email format hasn't been checked
UNless email becomes a top-level attribute this is not something we will validate. Validate in the client or make it a top-level attribute. ** Changed in: keystone Status: Triaged => 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/1218682 Title: User's email format hasn't been checked Status in OpenStack Identity (keystone): Invalid Status in oslo-incubator: Won't Fix Status in python-keystoneclient: Invalid Bug description: When a user is created, the email attribute can be in any format. I think it's necessary to do the format check of email. $ keystone user-list +--++-+---+ |id| name | enabled | email | +--++-+---+ | 4d0458857e604f0e9ceeefdea61f92a2 |testuser| True | test_user@@ | To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1218682/+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 1329554] Re: Setting token hashing to greater than sha256 will not work with the SQL token backend
** Changed in: keystone Status: Triaged => Won't Fix -- 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/1329554 Title: Setting token hashing to greater than sha256 will not work with the SQL token backend Status in OpenStack Identity (keystone): Won't Fix Bug description: The SQL Token backend sets the ID of the token to a 64 column. sha512 will generate a 128 character (byte) string. >>> a =hashlib.sha512('test').hexdigest() >>> a 'ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff' >>> len(a) 128 >>> To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329554/+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 1400737] Re: An index name is inappropriate to a naming convention
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Assignee: Viktor Serhieiev (vsergeyev) => (unassigned) ** Changed in: keystone Status: Incomplete => 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/1400737 Title: An index name is inappropriate to a naming convention Status in OpenStack Identity (keystone): Invalid Bug description: The index added in the 54 version was named inappropriate to the naming convention used by models. Need to fix index name. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1400737/+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 1398748] Re: MySQL engine doesn't specified at a table s with foreign key constraint.
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Ilya Pekelny (i159) => (unassigned) -- 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/1398748 Title: MySQL engine doesn't specified at a table s with foreign key constraint. Status in OpenStack Identity (keystone): Invalid Bug description: By default the CI uses MyISAM MySQL engine which doesn't support foreign key constraint. Thus we must explicitly sign MySQL engine as InnoDB at every table declares foreign keys or which is a fk target. Otherwise foreign keys can't be declared. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1398748/+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 1400589] Re: default region name is inconsistent with the hint message
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Dave Chen (wei-d-chen) => (unassigned) -- 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/1400589 Title: default region name is inconsistent with the hint message Status in OpenStack Identity (keystone): Invalid Bug description: It seems the name of the default region is RegionOne with the initial character "R" in upper case. MariaDB [keystone]> select * from region; +---+-+--+---+--+ | id| description | parent_region_id | extra | url | +---+-+--+---+--+ | RegionOne | | NULL | {}| NULL | | test | | NULL | {}| NULL | +---+-+--+---+--+ While I am try to create one new endpoint with a new region which I hope would be "regionOne", the command can be executed successfully, $ keystone endpoint-create --region regionOne --service a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 --adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0 +-+--+ | Property | Value | +-+--+ | adminurl | http://10.*.*.*:5010/v2.0 | | id | 8ffb333e32a54355bc924e7602362675 | | internalurl | http://10.*.*.*:5010/v2.0 | | publicurl | http://10.*.*.*:5010/v2.0 | |region |regionOne | | service_id | a1663c0dbba64425b5767688ac86fa10 | +-+--+ But there is no new region named "regionOne" created in the database other that the default one "RegionOne", so I guess it treats both of them the same. But if I create the endpoint with "RegionOne", the command can also success but the output message like this, $ keystone endpoint-create --region RegionOne --service a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 --adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0 +-+--+ | Property | Value | +-+--+ | adminurl | http://10.*.*.*:5010/v2.0 | | id | 075b237859c149128c3bbf8c3556922d | | internalurl | http://10.*.*.*:5010/v2.0 | | publicurl | http://10.*.*.*:5010/v2.0 | |region |RegionOne | | service_id | a1663c0dbba64425b5767688ac86fa10 | +-+--+ It make me confusion about what's behind about the region, so file this bug to track this. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1400589/+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 1185994] Re: identity-api doc: lack of clarity on X-Auth-Token vs X-Subject-Token
documentation has been improved in the specs repo: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity- api-v3.html ** Changed in: keystone Status: Triaged => Fix Released -- 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/1185994 Title: identity-api doc: lack of clarity on X-Auth-Token vs X-Subject-Token Status in OpenStack Identity (keystone): Fix Released Bug description: This is feedback from simo on IRC. The identity API doc has a few brief snippets [1] [2] [3] [4] describing what each header is for independently, but never directly compares them to explain when to use each and how to translate usage of one to the other. Specifically, it would be very beneficial to have a paragraph explaining the "flow" of these token values starting with authentication to usage against a non-Identity API, to online validation against keystone. [1]: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#required-attributes [2]: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#tokens [3]: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#authentication-responses [4]: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#validate-token-get-authtokens To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1185994/+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 1361441] Re: better handling for expired signing_cert.pem
PKI Tokens are deprecated, this is not something we're likely to fix due to the deprecation and low priority. ** Changed in: keystone Status: Confirmed => Won't Fix -- 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/1361441 Title: better handling for expired signing_cert.pem Status in OpenStack Identity (keystone): Won't Fix Bug description: While working on Barbican, I noted failing user authentications even though I have a valid token. I had to debug the openssl calls to see that the root cause was an expired signing_cert.pem file. Tracked this down to my keystone server, but had a hard time finding out how to resolve this situation. Asked on IRC and a launchpad bug was suggested, so here it is. I think there are actually 2 issues here: 1) some doc on how to handle expired certs - maybe just a paragraph in troubleshooting about using keystone_manage and also cleaning up client caches. 2) better ffdc (first failure data capture) so that the user (Barbican in this case) will see that the root cause was an expired cert rather than just a failed authentication. I also found this (slightly) related question in ask.openstack: https://ask.openstack.org/en/question/6402/keystone-ssl-certificate- expires-after-one-year/ and http://www.blackmesh.com/blog/openstack-refusing-authentication-psh Thanks!! To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1361441/+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 1360553] Re: Add memcached_backend option in keystone.conf
Was incomplete ages ago, inactive and generally not needed now with oslo_cache etc. ** Changed in: keystone Status: Incomplete => 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/1360553 Title: Add memcached_backend option in keystone.conf Status in OpenStack Identity (keystone): Invalid Bug description: If we choose memcached as the token backend driver, we should set proper servers in '[memcache]' section of keystone.conf. For the memcache backend, there are 3 memcached client supported by dogpile, --- # pydoc dogpile.cache.backends.memcached dogpile.cache.api.CacheBackend(__builtin__.object) GenericMemcachedBackend BMemcachedBackend MemcachedBackend(MemcacheArgs, GenericMemcachedBackend) PylibmcBackend(MemcacheArgs, GenericMemcachedBackend) In keystone, they are listed in keystone/common/kvs/backends/memcached.py: VALID_DOGPILE_BACKENDS = dict(pylibmc=memcached.PylibmcBackend, bmemcached=memcached.BMemcachedBackend, memcached=memcached.MemcachedBackend) By default, memcached will be used. The "memcached_backend" option will determine which backend to use. But there is no simple to pass the "memcached_backend" option. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1360553/+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 1472057] Re: in the function of create_trust,the judgment for “remaining_uses” can be deleted
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Deepti Ramakrishna (dramakri) => (unassigned) -- 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/1472057 Title: in the function of create_trust,the judgment for “remaining_uses” can be deleted Status in OpenStack Identity (keystone): Invalid Bug description: In the function of create_trust (Corresponding file is:/keystone/trust/core.py),the judgment for “remaining_uses” can be deleted, because controller has registered a schema to validate a resource reference. if not redelegatable: trust['redelegation_count'] = requested_count = 0 remaining_uses = trust.get('remaining_uses') if remaining_uses is not None and remaining_uses <= 0: # i think this judgment redundancy msg = _('remaining_uses must be a positive integer or null.') raise exception.ValidationError(msg) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472057/+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 1466846] Re: the function _config_to_list is not working well
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Henry Nash (henry-nash) => (unassigned) -- 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/1466846 Title: the function _config_to_list is not working well Status in OpenStack Identity (keystone): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: keystone\resource\core.py: in line 896 the function _config_to_list is not working well the return volue (whitelisted, sensitiveto) is alwayle [] To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1466846/+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 1441733] Re: pip install or python setup.py install should include httpd/keystone.py
This has been mostly eliminated as the wsgi scripts are now generated by pbr. ** Changed in: keystone Status: Incomplete => 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/1441733 Title: pip install or python setup.py install should include httpd/keystone.py Status in OpenStack Identity (keystone): Invalid Status in puppet-keystone: Confirmed Bug description: Now the recommended way to install keystone is via apache. But httpd/keystone.py is not included when we do python setup.py install in keystone. It should be included To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1441733/+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 1469472] Re: v3_to_v2 token conversion code does not support trusts
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Morgan Fainberg (mdrnstm) => (unassigned) -- 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/1469472 Title: v3_to_v2 token conversion code does not support trusts Status in OpenStack Identity (keystone): Invalid Bug description: v3 to v2 token conversion code does not support trusts. This is incorrect as v2 tokens are allowed to have trust data. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1469472/+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 1443104] Re: Owners logout from Horizon are not allowed to delete token with v2 API.
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: hongxiaolong (hongxiaolong-info) => (unassigned) -- 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/1443104 Title: Owners logout from Horizon are not allowed to delete token with v2 API. Status in OpenStack Identity (keystone): Invalid Bug description: Delete token by owner (Logout from Horizon) as follows: curl -i -X DELETE http://0.0.0.0:5000/v2.0/tokens/0c9d279867564955a98767b6493e8f30 -H "User-Agent: python-keystoneclient" -H "X-Auth-Token: d13e923d3424485b8edae3496b9905be" Then get a "403 Forbidden" response caused by policy "admin_required" in assert_admin() in the API named "delete_token". HTTP/1.1 403 Forbidden Date: Sun, 12 Apr 2015 13:43:55 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5 Vary: X-Auth-Token x-openstack-request-id: req-f5097bcd-764d-4e72-8aee-0382df15bfbc Content-Length: 186 Content-Type: application/json {"error": {"message": "You are not authorized to perform the requested action: identity:delete_token (Disable debug mode to suppress these details.)", "code": 403, "title": "Forbidden"}} Also, there will be an error message in horizon logs: Could not delete token The problem mainly causes by unreasonable admin role, those member users logout out from horizon unable to delete their own tokens, resulting in large numbers of redundancy tokens. In fact, it should be deleted by admin and owner. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1443104/+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 1413538] Re: untested or excessive dict comprehension
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Boris Bobrov (bbobrov) => (unassigned) -- 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/1413538 Title: untested or excessive dict comprehension Status in OpenStack Identity (keystone): Invalid Bug description: in keystone/contrib/federation/utils.py def extract_groups(groups_by_domain): for groups in groups_by_domain.values(): for group in {g['name']: g for g in groups}.values(): >> this is invalid syntax in python 2.6 yield group # initialize the group_ids as a set to eliminate duplicates user_name = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1413538/+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 1459686] Re: Give more details about the K2K flow
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Marek Denis (marek-denis) => (unassigned) -- 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/1459686 Title: Give more details about the K2K flow Status in OpenStack Identity (keystone): Invalid Bug description: Currently, the K2K flow in the config file [1] isn't detailed enough, we should provide at least the next step where we exchange a SAML assertion for a unscoped token from the SP. [1] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst #testing-it-all-out To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459686/+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 1509683] Re: sometimes the sheepdogdriver doesn't work when copy_image_to_volume
** No longer affects: keystone -- 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/1509683 Title: sometimes the sheepdogdriver doesn't work when copy_image_to_volume Status in Cinder: New Bug description: The sheepdog driver supports the function of copy_image_to_volume, but it can only write the image file to local sheepdog. In many cases, the cinder-volume is not depolyed on sheepdog node, so the copy_image_to_volume method doesn't work in those usage scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1509683/+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 1319370] Re: Uncontested reflection models to a test database
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Viktor Serhieiev (vsergeyev) => (unassigned) -- 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/1319370 Title: Uncontested reflection models to a test database Status in OpenStack Identity (keystone): Invalid Bug description: All the metadata models uncontested reflect to a test database even if migrations has been already synced. * In-file database synchronization https://github.com/openstack/keystone/blob/master/keystone/tests/ksfixtures/database.py#L46 * Uncontested metadata reflection https://github.com/openstack/keystone/blob/master/keystone/tests/ksfixtures/database.py#L121 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1319370/+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 1503741] Re: Admin with project-scoped token unable to list of users (got 401 HTTP Code)
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Boris Bobrov (bbobrov) => (unassigned) -- 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/1503741 Title: Admin with project-scoped token unable to list of users (got 401 HTTP Code) Status in OpenStack Identity (keystone): Invalid Bug description: Steps to reproduce: 1)Get project-scoped token for admin user (using API: http://address:port/v3/auth/tokens) with header "Content-Type: application/json" and body { "auth": { "identity": { "methods": ["password"], "password": { "user": {" "name": "admin", "domain": { "id": "default" }, "password": "adminpwd" } } }, "scope": { "project": { "name": "project_name", "domain": { "id": "default" } } } } } 2)Using token from step 1 (from header "X-Subject-Token") get the list of users (API: http://address:port/v3/users) with headers "Content- Type: application/json" and "X-Auth-Token: token_from_step_1" Expected result: Admin with project-scoped should be able to list users Actual result: Admin with project-scoped can't list users - there is 401 HTTP code and following body of response { "error": { "message": "The request you have made requires authentication. (Disable debug mode to suppress these details.)", "code": 401, "title": "Unauthorized" } } But admin with domain-scoped can list users. In policy.json is following rule for list_users: "rule:admin_required" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1503741/+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 1373599] Re: Trust operations in policy.json are misleading
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Nathan Kinder (nkinder) => (unassigned) -- 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/1373599 Title: Trust operations in policy.json are misleading Status in OpenStack Identity (keystone): Invalid Bug description: The sample policy.json files included in Keystone have the trust API operations listed. For example: "identity:create_trust": "user_id:%(trust.trustor_user_id)s", "identity:get_trust": "rule:admin_or_owner", "identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:check_role_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", This implies that these trust operations are protected by policy, which is true but misleading. While policy does protect these operations, they are hardcoded to be very restrictive. Here are some examples from the controller code: -- @controller.protected() def delete_trust(self, context, trust_id): trust = self.trust_api.get_trust(trust_id) if not trust: raise exception.TrustNotFound(trust_id=trust_id) user_id = self._get_user_id(context) _admin_trustor_only(context, trust, user_id) self.trust_api.delete_trust(trust_id) @controller.protected() def list_roles_for_trust(self, context, trust_id): trust = self.get_trust(context, trust_id)['trust'] if not trust: raise exception.TrustNotFound(trust_id=trust_id) user_id = self._get_user_id(context) _trustor_trustee_only(trust, user_id) return {'roles': trust['roles'], 'links': trust['roles_links']} -- In the trust controller code, the following restrictions are currently hard-coded: create_trust - trustor only get_trust - trustor or trustee only l ist_trusts - admin only to list all trusts, trustor or trustee only for related trusts list_roles_for_trust - trustor or trustee only check_role_for_trust - trustor or trustee only get_role_for_trust - trustor or trustee only (indirectly via check_role_for_trust) delete_trust - admin or trustor only The policies in policy.json can make these operations more restricted, but not less restricted than the hard-coded restrictions. We can't simply remove these settings from policy.json, as that would cause the "default" rule to be used which makes trusts unusable in the case of the default "default" rule of "admin_required". This only leaves us with the option of clearly documenting the behavior IMHO. Unfortunately, JSON doesn't allow comments, so we can't just add nice comments right there in policy.json. I think that the correct approach is: - Add a general purpose paragraph to the RBAC section of doc/source/configuration.rst that states that some operations have hard-coded restrictions that policy is unable to circumvent. Mention that policy can still make these operations more restrictive. - Add documentation for the trust extension at keystone/doc/source/extensions/trust.rst that mentions the hard-coded restrictions for each trust operation. Documentation for the trust extension in this area is completely missing at this time. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1373599/+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 1347262] Re: Ldap Live test failures
Marking as invalid since this should have expired as incomplete long ago. ** Changed in: keystone Status: Incomplete => Invalid ** Changed in: keystone Assignee: Arun Kant (arunkant-uws) => (unassigned) -- 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/1347262 Title: Ldap Live test failures Status in OpenStack Identity (keystone): Invalid Bug description: In keystone master, when live ldap test are executed against local openldap instance, 7 tests are failing. 3 tests fail with following error. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/mock.py", line 1201, in patched return func(*args, **keywargs) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/tests/test_backend_ldap.py", line 1156, in test_chase_referrals_off user_api.get_connection(user=None, password=None) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 965, in get_connection conn.simple_bind_s(user, password) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 638, in simple_bind_s serverctrls, clientctrls) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/tests/fakeldap.py", line 246, in simple_bind_s attrs = self.db[self.key(who)] AttributeError: 'FakeLdap' object has no attribute 'db' The tests which are failing with above error are LiveLDAPIdentity.test_chase_referrals_off LiveLDAPIdentity.test_chase_referrals_on LiveLDAPIdentity.test_debug_level_set Reason: In FakeLdap, the livetest creds are different from backend_ldap.conf and does not match at https://github.com/openstack/keystone/blob/master/keystone/tests/fakeldap.py#L242 1 test fails with following error Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/mock.py", line 1201, in patched return func(*args, **keywargs) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/tests/test_backend_ldap.py", line 1288, in test_user_mixed_case_attribute user['email']) KeyError: 'email' Test failed: LiveLDAPIdentity.test_user_mixed_case_attribute Reason: CONF.ldap.user_mail_attribute is different in live test. Its mail and not email as in backend_ldap.conf so test code needs to be changed to handle both scenarios. 2 tests fails with following error Traceback (most recent call last): File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/tests/test_backend_ldap.py", line 695, in test_user_id_comma user = self.identity_api.driver.create_user(user_id, user) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/identity/backends/ldap.py", line 94, in create_user user_ref = self.user.create(user) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/identity/backends/ldap.py", line 230, in create values = super(UserApi, self).create(values) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 1390, in create ref = super(EnabledEmuMixIn, self).create(values) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 1085, in create conn.add_s(self._id_to_dn(values['id']), attrs) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 656, in add_s return self.conn.add_s(dn_utf8, ldap_attrs_utf8) File "/home/arunkant-uws/myFolder/myWork/openstack/keystone/keystone/common/ldap/core.py", line 551, in add_s return self.conn.add_s(dn, modlist) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 194, in add_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) UNDEFINED_TYPE: {'info': 'domain_id: AttributeDescription contains inappropriate characters', 'desc': 'Undefined attribute type'} Test failed: LiveLDAPIdentity.test_user_id_comma LiveLDAPIdentity.test_user_id_comma_grants Reason: Related test code creates user using driver instead of using identity api which filters domain_id from response. Possible solution: Line 695 , 714, 749 in https://re
[Yahoo-eng-team] [Bug 1336769] Re: LDAP additional attribute mappings description do not specify that they are for creation only
marking as invalid, since the options are deprecated, let's just remove them ** Changed in: keystone Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1336769 Title: LDAP additional attribute mappings description do not specify that they are for creation only Status in OpenStack Identity (keystone): Invalid Bug description: Additional attribute mappings can be used to map ldap attributes to internal keystone attributes. This allows keystone to fulfill ldap objectclass requirements. List of additional LDAP attributes used for mapping additional attribute mappings for users (or projects). Attribute mapping format is :, where ldap_attr is the attribute in the LDAP entry and model_attr is the Identity API attribute. (list value). So far so good. Now, following next steps: 1- Apply this patch https://review.openstack.org/#/c/91490/ 2- Add this parameter to keystone.conf file tenant_additional_attribute_mapping = objectCategory:notexistingfield1, whenChanged:notexistingfield2 3- Add 'objectCategory' and 'whenChanged' LDAP parameters to Project model on keystone/common/models.py class Project(Model): required_keys = ('id', 'name', 'domain_id') optional_keys = ('description', 'enabled', 'objectCategory', 'whenChanged') 4- Restart keystone 5- Execute this in command line: curl -H "X-Auth-Token:admin_token" http://localhost:5000/v3/projects Everything works perfectly!. you can see the info of 'objectCategory' and 'whenChanged' LDAP parameters in the JSON string returned by CURL... and it should not (I think) works, because "notexistingfield1" and "notexistingfield2" are not real fields. I have a mistake in the keystone.conf file and everything is working properly. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1336769/+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 1541119] [NEW] Running neutron unit tests creates 'fip-priorities' file in directory
Public bug reported: I noticed a couple of untracked files in my git repo, one being 'fip- priorities'. I deleted it and re-ran 'tox -e py27', but it was re- created: --> cat fip-priorities ,67778 dvr_fip_ns.py is where it's used in a path definition, but it's actually in the ItemAllocator class where the file is read and written. Since this is a unit test it should have been mocked-out so the file is not created, just need to track down where to do that. ** 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/1541119 Title: Running neutron unit tests creates 'fip-priorities' file in directory Status in neutron: New Bug description: I noticed a couple of untracked files in my git repo, one being 'fip- priorities'. I deleted it and re-ran 'tox -e py27', but it was re- created: --> cat fip-priorities ,67778 dvr_fip_ns.py is where it's used in a path definition, but it's actually in the ItemAllocator class where the file is read and written. Since this is a unit test it should have been mocked-out so the file is not created, just need to track down where to do that. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1541119/+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 1524568] Re: Automatically generate neutron LBaaS configuration files
Reviewed: https://review.openstack.org/262824 Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=14ceea05212d84808aeac8017cf11b205f5c8678 Submitter: Jenkins Branch:master commit 14ceea05212d84808aeac8017cf11b205f5c8678 Author: venkatamahesh Date: Fri Jan 1 00:36:18 2016 +0530 [config-ref] Auto-generation of neutron-vpnaas/lbaas conf files From mitaka, the neutron-vpnaas and neutron-lbaas configuration files are auto-generated and so updated the documentation Change-Id: Ia82048e704f5501e940adb1670df2db160b3753c Closes-Bug: #1524568 Closes-Bug: #1525424 ** Changed in: openstack-manuals Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1524568 Title: Automatically generate neutron LBaaS configuration files Status in neutron: Fix Released Status in openstack-manuals: Fix Released Bug description: DocImpact for LBaaS https://review.openstack.org/252981 commit e719861c00ab1e50e271c3bcdbc0b9130353d2d4 Author: Martin Hickey Date: Thu Dec 3 14:39:29 2015 + Automatically generate neutron LBaaS configuration files This adds a new tox environment, genconfig, which generates sample neutron LBaaS configuration file using oslo-config-generator. DocImpact: Update the docs that LBaaS no longer includes static example configuration files. Instead, use tools/generate_config_file_samples.sh to generate them and the files generated now end with .sample extension. Partially-Implements: blueprint autogen-neutron-conf-file Change-Id: I25507f3bc6e995580aa91a912c2cf4110757df15 Partial-bug: #1199963 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1524568/+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 1525424] Re: Automatically generate neutron VPNaaS configuration files
Reviewed: https://review.openstack.org/262824 Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=14ceea05212d84808aeac8017cf11b205f5c8678 Submitter: Jenkins Branch:master commit 14ceea05212d84808aeac8017cf11b205f5c8678 Author: venkatamahesh Date: Fri Jan 1 00:36:18 2016 +0530 [config-ref] Auto-generation of neutron-vpnaas/lbaas conf files From mitaka, the neutron-vpnaas and neutron-lbaas configuration files are auto-generated and so updated the documentation Change-Id: Ia82048e704f5501e940adb1670df2db160b3753c Closes-Bug: #1524568 Closes-Bug: #1525424 ** Changed in: openstack-manuals Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525424 Title: Automatically generate neutron VPNaaS configuration files Status in neutron: Fix Released Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/253399 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71 Author: Martin Hickey Date: Fri Dec 4 09:10:04 2015 + Automatically generate neutron VPNaaS configuration files This adds a new tox environment, genconfig, which generates sample neutron VPNaaS configuration file using oslo-config-generator. Updates to some configuration option help messages to reflect useful details that were missing in the code but were present in config files. DocImpact: Update the docs that VPNaaS no longer includes static example configuration files. Instead, use tools/generate_config_file_samples.sh to generate them and the files generated now end with .sample extension. Partially-Implements: blueprint autogen-neutron-conf-file Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551 Partial-bug: #1199963 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525424/+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 1531959] Re: mapping_id does not allow "_" character
Reviewed: https://review.openstack.org/264937 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=b81a8266d1e6248ca759d51ef1a003423887ee8a Submitter: Jenkins Branch:master commit b81a8266d1e6248ca759d51ef1a003423887ee8a Author: Roxana Gherle Date: Thu Jan 7 11:09:54 2016 -0800 Allow '_' character in mapping_id value Underscore character should be allowed in mapping_id. Closes-Bug: #1531959 Change-Id: I4235e09ff68f68bbe4cf5c4e9aeaef2b79484f94 ** Changed in: keystone Status: In Progress => Fix Released -- 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/1531959 Title: mapping_id does not allow "_" character Status in OpenStack Identity (keystone): Fix Released Bug description: The underscore character is not allowed in mapping_id because the validation of the parameter value is done with the id_string regex pattern '^[a-zA-Z0-9-]+$' which doesn't include '_'. Underscore character should be allowed in a mapping id validation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1531959/+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 1538163] Re: DVR: race in dvr serviceable port deletion
Reviewed: https://review.openstack.org/272634 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c74265efb9339bee6011851d8a160067854a2818 Submitter: Jenkins Branch:master commit c74265efb9339bee6011851d8a160067854a2818 Author: Oleg Bondarev Date: Tue Jan 26 18:01:50 2016 +0300 DVR: avoid race on dvr serviceable port deletion Please see race details in the bug report. The fix is to check for dvr routers that needs to be removed after actual port deletion. As a bonus we can get rid of dvr logic in ml2 plugin delete_port(). It's hard to come up with a test here as race can only be reproduced with multiple API workers. Closes-Bug: #1538163 Change-Id: I7ab1b0c18e5daa6f35a37370b9be79e689e2ba50 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1538163 Title: DVR: race in dvr serviceable port deletion Status in neutron: Fix Released Bug description: In ml2 plugin when dvr seviceable port is deleted, we check if any dvr routers should be deleted from port's host. This is done prior to actual port deletion from db by checking if there are any more dvr serviceable ports on this host. This is prone to races: if two last compute ports on the host are deleted concurrently, the check might not return any routers as in both cases it will see yet another dvr serviceable port on the host: - p1 and p2 are last compute ports on compute host 'host1' - p1 and p2 are on the same subnet connected to a dvr router 'r1' - p1 and p2 are deleted concurrently - on p1 deletion plugin checks if there are any more dvr serviceable ports on host1 - sees p2 -> no dvr routers should be deleted - same on p2 deletion plugin checks if there are any more dvr serviceable ports on host1 - sees p1 -> no dvr routers should be deleted - p1 is deleted from DB - p2 is deleted from DB - r1 is not deleted from host1 though there are no more ports on it To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1538163/+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 1541191] [NEW] Limit to create only one external network
Public bug reported: Since L3 agent support only one external network, https://github.com/openstack/neutron/blob/master/neutron/db/external_net_db.py#L149 But now, we can create any number of external network that will cause to raise TooManyExternalNetworks exception in agent rpc get_external_network_id(). We should modify create_network api to limit only one external_network could be create. ** Affects: neutron Importance: Undecided Assignee: yaowei (yaowei) Status: New ** Changed in: neutron Assignee: (unassigned) => yaowei (yaowei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1541191 Title: Limit to create only one external network Status in neutron: New Bug description: Since L3 agent support only one external network, https://github.com/openstack/neutron/blob/master/neutron/db/external_net_db.py#L149 But now, we can create any number of external network that will cause to raise TooManyExternalNetworks exception in agent rpc get_external_network_id(). We should modify create_network api to limit only one external_network could be create. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1541191/+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 1541192] [NEW] Set default value for dnsmasq_local_resolv to False
Public bug reported: https://review.openstack.org/269822 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 003091a97480f12ea2fe948b6b9d8b4646d9463f Author: armando-migliaccio Date: Tue Jan 19 11:25:05 2016 -0800 Set default value for dnsmasq_local_resolv to False patch 0de1d8d4c introduced a new behavior whereby dnsmasq can rely on dns resolvers defined in the host's resolv.conf, and it did that by default. However this may introduce dns timeouts if the dns servers are not reachable for whatever reason. This may be especially likely in certain gate configurations (where the VM under test is a guest itself). Regardless of the root-cause analysis, this option should have defaulted to False to preserve backward compatibility, therefore this patch restores the old behavior in a way that local DNS resolution occurs only if the new option variable is set to True, or the admin has not explicitly set the list of DNS servers to be injected in the DHCP response. DocImpact: document how to configure DNS resolution by dnsmasq Change-Id: I90ab26bfa83c2d23c92110b8da73ef771e11f7bb ** 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/1541192 Title: Set default value for dnsmasq_local_resolv to False Status in neutron: New Bug description: https://review.openstack.org/269822 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 003091a97480f12ea2fe948b6b9d8b4646d9463f Author: armando-migliaccio Date: Tue Jan 19 11:25:05 2016 -0800 Set default value for dnsmasq_local_resolv to False patch 0de1d8d4c introduced a new behavior whereby dnsmasq can rely on dns resolvers defined in the host's resolv.conf, and it did that by default. However this may introduce dns timeouts if the dns servers are not reachable for whatever reason. This may be especially likely in certain gate configurations (where the VM under test is a guest itself). Regardless of the root-cause analysis, this option should have defaulted to False to preserve backward compatibility, therefore this patch restores the old behavior in a way that local DNS resolution occurs only if the new option variable is set to True, or the admin has not explicitly set the list of DNS servers to be injected in the DHCP response. DocImpact: document how to configure DNS resolution by dnsmasq Change-Id: I90ab26bfa83c2d23c92110b8da73ef771e11f7bb To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1541192/+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 1505893] Re: test_ha_router_failover fails with timeout
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1505893 Title: test_ha_router_failover fails with timeout Status in neutron: Expired Bug description: http://logs.openstack.org/02/233802/2/check/gate-neutron-dsvm- functional/0b1a964/testr_results.html.gz message:"in test_ha_router_failover" http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiaW4gdGVzdF9oYV9yb3V0ZXJfZmFpbG92ZXJcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQ0NDc5NjQwODk4MX0= 3 instances during the last 7 days. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1505893/+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 1488282] Re: Gate failures with 'the resource could not be found'
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1488282 Title: Gate failures with 'the resource could not be found' Status in neutron: Expired Bug description: There have been spurious failures happening in the gate. The most prominent one is: ft1.186: tempest.api.compute.admin.test_servers.ServersAdminTestJSON.test_list_servers_by_admin_with_all_tenants[id-9f5579ae-19b4-4985-a091-2a5d56106580]_StringException: Empty attachments: stderr stdout pythonlogging:'': {{{ 2015-08-24 22:55:50,083 32355 INFO [tempest_lib.common.rest_client] Request (ServersAdminTestJSON:test_list_servers_by_admin_with_all_tenants): 404 GET http://127.0.0.1:8774/v2/fb99c79318b54e668713b25afc52f81a/servers/detail?all_tenants= 0.834s 2015-08-24 22:55:50,083 32355 DEBUG[tempest_lib.common.rest_client] Request - Headers: {'X-Auth-Token': '', 'Accept': 'application/json', 'Content-Type': 'application/json'} Body: None Response - Headers: {'content-length': '78', 'date': 'Mon, 24 Aug 2015 22:55:50 GMT', 'connection': 'close', 'content-type': 'application/json; charset=UTF-8', 'x-compute-request-id': 'req-387b21a9-4ada-48ee-89ed-9acfe5274ef7', 'status': '404'} Body: {"itemNotFound": {"message": "The resource could not be found.", "code": 404}} }}} Traceback (most recent call last): File "tempest/api/compute/admin/test_servers.py", line 81, in test_list_servers_by_admin_with_all_tenants body = self.client.list_servers(detail=True, **params) File "tempest/services/compute/json/servers_client.py", line 159, in list_servers resp, body = self.get(url) File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py", line 271, in get return self.request('GET', url, extra_headers, headers) File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py", line 643, in request resp, resp_body) File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py", line 695, in _error_checker raise exceptions.NotFound(resp_body) tempest_lib.exceptions.NotFound: Object not found Details: {u'code': 404, u'message': u'The resource could not be found.'} but there are other similar failure modes. This seems to be related to bug #1269284 The logstash query: message:"tempest_lib.exceptions.NotFound: Object not found" AND build_name:"gate-tempest-dsvm-neutron-full" http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVtcGVzdF9saWIuZXhjZXB0aW9ucy5Ob3RGb3VuZDogT2JqZWN0IG5vdCBmb3VuZFwiIEFORCBidWlsZF9uYW1lOlwiZ2F0ZS10ZW1wZXN0LWRzdm0tbmV1dHJvbi1mdWxsXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0NDA0NjIwNzcyMjksIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0= To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1488282/+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 1541196] [NEW] Limit file permissions on /var/log/cloud-init.log
Public bug reported: It seems that both /var/log/cloud-init.log and /var/log/cloud-init- output.log files are created with the files as publicly readable (specifically 0644 file permissions) ``` brandon@:~$ ls -al /var/log/cloud-init* -rw-r--r-- 1 syslog adm 1060887 Jan 26 05:23 /var/log/cloud-init.log -rw-r--r-- 1 root root 18666 Jan 26 05:23 /var/log/cloud-init-output.log ``` Are there concerns with these being publicly readable? I don't have any specific examples of confidential information that may be exposed via these logs, but wouldn't it seem prudent to limit file permissions in case there was some unintended secrets output from another application or user-defined scripts that are run via cloudinit? ** 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/1541196 Title: Limit file permissions on /var/log/cloud-init.log Status in cloud-init: New Bug description: It seems that both /var/log/cloud-init.log and /var/log/cloud-init- output.log files are created with the files as publicly readable (specifically 0644 file permissions) ``` brandon@:~$ ls -al /var/log/cloud-init* -rw-r--r-- 1 syslog adm 1060887 Jan 26 05:23 /var/log/cloud-init.log -rw-r--r-- 1 root root 18666 Jan 26 05:23 /var/log/cloud-init-output.log ``` Are there concerns with these being publicly readable? I don't have any specific examples of confidential information that may be exposed via these logs, but wouldn't it seem prudent to limit file permissions in case there was some unintended secrets output from another application or user-defined scripts that are run via cloudinit? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1541196/+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 1541201] [NEW] deprecate pki related commands
Public bug reported: with PKI deprecated, we should deprecate pki_setup and ssl_setup ** Affects: keystone Importance: Medium Status: Triaged ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Milestone: None => mitaka-3 -- 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/1541201 Title: deprecate pki related commands Status in OpenStack Identity (keystone): Triaged Bug description: with PKI deprecated, we should deprecate pki_setup and ssl_setup To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1541201/+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 1540495] Re: Version 0.2.8 of xvfbwrapper breaks integration tests
Reviewed: https://review.openstack.org/275401 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=78bfa9727da5e653cd46fbea5f2e348c32905154 Submitter: Jenkins Branch:master commit 78bfa9727da5e653cd46fbea5f2e348c32905154 Author: Victor Stinner Date: Tue Feb 2 21:43:49 2016 +0100 Support xvfbwrapper 0.2.8 xvfbwrapper 0.2.8 renamed the xvfb_cmd attribute of xvfbwrapper.Xvfb to extra_xvfb_args. This change checks if the new attribute name is available to support new and old xvfbwrapper version. xvfbwrapper commit changing the API: https://github.com/cgoldberg/xvfbwrapper/commit/9a8c0e80f6a932d5448d1b97d5a9c316a7a7c8e3 Closes-Bug: #1540495 Change-Id: I45704450ff396787453937362029945b94887189 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1540495 Title: Version 0.2.8 of xvfbwrapper breaks integration tests Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Version 0.2.8 (released on Jan 31) breaks all integration tests with stacktrace 2016-02-01 16:58:10.961 | 2016-02-01 16:58:10.904 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py", line 160, in setUp 2016-02-01 16:58:10.961 | 2016-02-01 16:58:10.905 | super(TestCase, self).setUp() 2016-02-01 16:58:10.961 | 2016-02-01 16:58:10.907 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py", line 60, in setUp 2016-02-01 16:58:10.962 | 2016-02-01 16:58:10.909 | self.vdisplay.xvfb_cmd.append("-noreset") 2016-02-01 16:58:10.962 | 2016-02-01 16:58:10.910 | AttributeError: Xvfb instance has no attribute 'xvfb_cmd' The solution is to adapt to new version by passing additional arguments when initializing Xvfb instance (instead of appending them to xvfb_cmd list which doesn't exist now before .start() is invoked). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1540495/+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 1541218] [NEW] fail lots of V2 testcases due to no `policy.json` could be found
Public bug reported: How to reproduce: 1. remove the `/etc/keystone/policy.json` if there is since this file only exists after env is setup, this will make sure the test engine to search the `policy.json` in the code base, for example, load the policy file from here `/opt/stack/keystone/etc/policy.json` 2. run the v2 testcases separately, $ python -m unittest keystone.tests.unit.test_v2 or simply run only one testcases. $ python -m unittest keystone.tests.unit.test_credential.TestCredentialEc2.test_ec2_list_credentials 3. You will hit the following exceptions. enforce identity:validate_token: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'180af26c59e9460f81652569d27fc439', 'roles': ['Service'], 'user_domain_id': 'default', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': , 'project_id': 'service', 'trust_id': None, 'project_domain_id': 'default'} Failed to find some config files: policy.json Traceback (most recent call last): File "keystone/common/wsgi.py", line 247, in __call__ result = method(context, **params) File "/usr/local/lib/python2.7/dist-packages/oslo_log/versionutils.py", line 165, in wrapped return func_or_cls(*args, **kwargs) File "keystone/common/controller.py", line 179, in inner utils.flatten_dict(policy_dict)) File "keystone/policy/backends/rules.py", line 77, in enforce enforce(credentials, action, target) File "keystone/policy/backends/rules.py", line 69, in enforce return _ENFORCER.enforce(action, target, credentials, **extra) File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 540, in enforce self.load_rules() File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 443, in load_rules self.policy_path = self._get_policy_path(self.policy_file) File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 513, in _get_policy_path raise cfg.ConfigFilesNotFoundError((path,)) ConfigFilesNotFoundError: Failed to find some config files: policy.json }}} Traceback (most recent call last): File "keystone/tests/unit/test_v2.py", line 186, in test_validate_token_service_role token=token) File "keystone/tests/unit/rest.py", line 208, in admin_request return self._request(app=self.admin_app, **kwargs) File "keystone/tests/unit/rest.py", line 197, in _request response = self.restful_request(**kwargs) File "keystone/tests/unit/rest.py", line 182, in restful_request **kwargs) File "keystone/tests/unit/rest.py", line 90, in request **kwargs) File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 567, in request expect_errors=expect_errors, File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 632, in do_request self._check_status(status, res) File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 664, in _check_status res) webtest.app.AppError: Bad response: 500 Internal Server Error (not 200 OK or 3xx redirect for http://localhost/v2.0/tokens/3c69de14762f42ac89852eb1f3c7eab5) '{"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}}' Ran 122 tests in 18.954s FAILED (errors=73, skipped=3) ** Affects: keystone Importance: Undecided Assignee: Dave Chen (wei-d-chen) Status: New ** Description changed: How to reproduce: 1. remove the `/etc/keystone/policy.json` if there is since this file only exists after env is setup, this will make sure the test engine to - search the `policy.json` in the code base, for example, load this - policy file. `/opt/stack/keystone/etc/policy.json` + search the `policy.json` in the code base, for example, load the policy + file from here `/opt/stack/keystone/etc/policy.json` - 2. run the v2 testcases seperately, + 2. run the v2 testcases separately, $ python -m unittest keystone.tests.unit.test_v2 or simply run only one testcases. $ python -m unittest keystone.tests.unit.test_credential.TestCredentialEc2 3. You will hit the following exceptions. enforce identity:validate_token: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'180af26c59e9460f81652569d27fc439', 'roles': ['Service'], 'user_domain_id': 'default', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': , 'project_id': 'service', 'trust_id': None, 'project_domain_id': 'default'} Failed to find some config files: policy.json Traceback (most recent call last): - File "keystone/common/wsgi.py", line 247, in __call__ - result = method(context, **params) - File "/usr/local/lib/python2.7/dist-packages/oslo_log/versionutils.py", line 165, in wrapped - return func_or_cls(*args, **kwargs) - File "keystone/common/controller.py", line 179, in inner - utils.flatten_dict(policy_dict)) - File "keystone/policy/backends/rules.py", line 77, in enforce - enforce(credentials, action, t
[Yahoo-eng-team] [Bug 1538754] Re: keystone should convert host CONF.federation.trusted_dashboard to lower case before comparing
Reviewed: https://review.openstack.org/273394 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=78c9ccc9eea34148364563508af6847481b9c9f4 Submitter: Jenkins Branch:master commit 78c9ccc9eea34148364563508af6847481b9c9f4 Author: Roxana Gherle Date: Thu Jan 28 00:11:02 2016 -0800 Make WebSSO trusted_dashboard hostname case-insensitive Ensure the hostname in the trusted_dashboard config is lowercase to prevent failures when comparing against the origin query URL. Closes-Bug: #1538754 Change-Id: I807a567e7d93c09c5c370065509c106b7d1c973b ** Changed in: keystone Status: In Progress => Fix Released -- 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/1538754 Title: keystone should convert host CONF.federation.trusted_dashboard to lower case before comparing Status in OpenStack Identity (keystone): Fix Released Bug description: https://github.com/openstack/keystone/blob/master/keystone/federation/controllers.py#L272 keystone should convert it to lower case before comparing It should not be case sensitive. Otherwise some uppercase hostname would fail to auth from browser etc. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1538754/+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 1541238] [NEW] No response message after we delete an image
Public bug reported: When an image is deleted there is no message on successful deletion. ** Affects: glance Importance: Undecided Assignee: M V P Nitesh (m-nitesh) Status: New ** Tags: glance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1541238 Title: No response message after we delete an image Status in Glance: New Bug description: When an image is deleted there is no message on successful deletion. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1541238/+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