[Yahoo-eng-team] [Bug 1771538] Re: PowerVM config drive path is not secure
** Also affects: nova-powervm 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/1771538 Title: PowerVM config drive path is not secure Status in OpenStack Compute (nova): In Progress Status in nova-powervm: New Bug description: This report is based on the Bandit scanner results and code review. 1) On https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/powervm/media.py?h=refs/heads/master#n44 43 _VOPT_SIZE_GB = 1 44 _VOPT_TMPDIR = '/tmp/cfgdrv/' 45 We have hardcoded tmp dir that could be cleaned up after compute node reboot. As mentioned in todo it might be good to use conf option. 2) On https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/powervm/media.py?h=refs/heads/master#n116 Predictable file name based on a user input is used: 116file_name = pvm_util.sanitize_file_name_for_api( 117instance.name, prefix='cfg_', suffix='.iso', 118max_len=pvm_const.MaxLen.VOPT_NAME) Probably we could use instance.uuid for that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1771538/+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 1784950] [NEW] get_device_details RPC fails if host not specified
Public bug reported: An optional (defaults to None) host argument was added to the get_device_details RPC method a long time ago [1] but a recent change [2] to the master branch has made that no longer really optional, at least for the pvm_sea agent from openstack/networking-powervm, since not passing it will cause VIF plugging to timeout with an error in the neutron logs stating "Device %s has no active binding in host None". This can easily be fixed in openstack/networking-powervm by passing the host argument, but I expect that neutron also needs to bump the version for neutron.plugins.ml2.rpc.RpcCallbacks to reflect that host is no longer optional by removing the "=None" default (since it doesn't work anymore). [1] f7064f2b6c6ba1d0ab5f9872b2d5ad7969a64e7b [2] 01bdb47199468805b714ce4c00c7492951267585 ** Affects: networking-powervm Importance: Undecided Status: New ** Affects: neutron Importance: Undecided Status: New ** Also affects: networking-powervm 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/1784950 Title: get_device_details RPC fails if host not specified Status in networking-powervm: New Status in neutron: New Bug description: An optional (defaults to None) host argument was added to the get_device_details RPC method a long time ago [1] but a recent change [2] to the master branch has made that no longer really optional, at least for the pvm_sea agent from openstack/networking-powervm, since not passing it will cause VIF plugging to timeout with an error in the neutron logs stating "Device %s has no active binding in host None". This can easily be fixed in openstack/networking-powervm by passing the host argument, but I expect that neutron also needs to bump the version for neutron.plugins.ml2.rpc.RpcCallbacks to reflect that host is no longer optional by removing the "=None" default (since it doesn't work anymore). [1] f7064f2b6c6ba1d0ab5f9872b2d5ad7969a64e7b [2] 01bdb47199468805b714ce4c00c7492951267585 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-powervm/+bug/1784950/+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 1781286] [NEW] CantStartEngineError in cell conductor during rebuild
Public bug reported:
In a stable/queens devstack environment with multiple PowerVM compute
nodes, everytime I see this in devstack@n-cond-cell1.service logs:
Jul 11 15:48:57 myhostname nova-conductor[3796]: DEBUG
nova.conductor.manager [None req-af22375c-f920-4747-bd2f-0de80ee69465
admin admin] Rescheduling: True {{(pid=4108) build_instances
/opt/stack/nova/nova/conductor/manager.py:571}}
it is shortly thereafter followed by:
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server [None req-af22375c-f920-4747-bd2f-0de80ee69465 admin
admin] Exception during message handling: CantStartEngineError: No
sql_connection parameter is established
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server Traceback (most recent call last):
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line
163, in _process_incoming
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server res = self.dispatcher.dispatch(message)
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line
220, in dispatch
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt,
args)
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line
190, in _do_dispatch
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server result = func(ctxt, **new_args)
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File "/opt/stack/nova/nova/conductor/manager.py",
line 652, in build_instances
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server host.service_host))
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File "/opt/stack/nova/nova/availability_zones.py",
line 95, in get_host_availability_zone
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server key='availability_zone')
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line
184, in wrapper
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server result = fn(cls, context, *args, **kwargs)
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File "/opt/stack/nova/nova/objects/aggregate.py",
line 541, in get_by_host
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server _get_by_host_from_db(context, host, key=key)]
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py",
line 987, in wrapper
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server with self._transaction_scope(context):
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File "/usr/lib/python2.7/contextlib.py", line 17,
in __enter__
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server return self.gen.next()
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py",
line 1037, in _transaction_scope
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server context=context) as resource:
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File "/usr/lib/python2.7/contextlib.py", line 17,
in __enter__
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server return self.gen.next()
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py",
line 640, in _session
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server bind=self.connection, mode=self.mode)
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py",
line 404, in _create_session
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server self._start()
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server File
"/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py",
line 491, in _start
Jul 11 15:48:57 myhostname nova-conductor[3796]: ERROR
oslo_messaging.rpc.server engine_args, maker_args)
Jul 11 15:48:57 myhostname
[Yahoo-eng-team] [Bug 1766692] Re: instance.uuid no longer being a str breaks powervm scsi disconnect
** Changed in: pypowervm 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/1766692 Title: instance.uuid no longer being a str breaks powervm scsi disconnect Status in OpenStack Compute (nova): In Progress Status in nova-powervm: Fix Released Status in pypowervm: Fix Released Bug description: Long-standing code in pypowervm [1] used isinstance(..., str) to help identify whether an input was a UUID or an integer short ID. This is used with to find SCSI mappings [2] with Instance.uuid [3] when disconnecting a disk during destroy [4]. Then this change in oslo.versionedobjects happened [5], resulting in instance.uuid no longer being a str. So the check at [1] fails, and we try to int() a UUID string, resulting in [6], pasted here in case that link expires: PowerVM error destroying instance.: ValueError: invalid literal for int() with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA' Traceback (most recent call last): File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 672, in _destroy _setup_flow_and_run() File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 668, in _setup_flow_and_run tf_base.run(flow, instance=instance) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/base.py", line 40, in run return eng.run() File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py", line 247, in run for _state in self.run_iter(timeout=timeout): File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter failure.Failure.reraise_if_any(er_failures) File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", line 336, in reraise_if_any failures[0].reraise() File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", line 343, in reraise six.reraise(*self._exc_info) File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task result = task.execute(**arguments) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/storage.py", line 452, in execute self.instance, stg_ftsk=self.stg_ftsk, disk_type=self.disk_type) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/disk/ssp.py", line 174, in disconnect_disk match_func=match_func) File "/usr/local/lib/python2.7/dist-packages/pypowervm/tasks/scsi_mapper.py", line 503, in find_maps is_uuid, client_id = uuid.id_or_uuid(client_lpar_id) File "/usr/local/lib/python2.7/dist-packages/pypowervm/utils/uuid.py", line 55, in id_or_uuid ret_id = int(an_id) ValueError: invalid literal for int() with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA' (Okay, our bad for using str at all - though to be fair, it's possible that code predates the very existence of py3.) The right fix is for [1] to use is_uuid_like from oslo.utils. This shall be done. However, since [5] was backported to queens and pike, unless we can get away with backporting requirements changes, we may have to do something backportable in nova-powervm and nova as well. [1] https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/utils/uuid.py#L50 [2] https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/tasks/scsi_mapper.py#L503 [3] https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/disk/ssp.py#L128 [4] https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/driver.py#L272 [5] https://review.openstack.org/#/q/Ic6b6308fb1960ec40407e6efde30137b64543e72 [6] http://184.172.12.213/58/557958/10/check/nova-out-of-tree-pvm/c1d7e99/logs/n-cpu.txt.gz?#_Apr_20_08_51_16_452651 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1766692/+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 1753585] [NEW] LDAP user name attribute is case sensitive
Public bug reported: keystone was not able to find any users while the LDAP user name attribute was configured to "samaccountname", but could find users when reconfigured to use "sAMAccountName". LDAP is not supposed to be case- sensitive, so either should work. This appears to be a result of https://github.com/openstack/keystone/blob/12.0.0.0rc2/keystone/identity/backends/ldap/common.py#L1403 looking for that attribute in a case-sensitive manner, though there may be other places as well. found in: Pike ** Affects: keystone Importance: Undecided Status: New -- 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/1753585 Title: LDAP user name attribute is case sensitive Status in OpenStack Identity (keystone): New Bug description: keystone was not able to find any users while the LDAP user name attribute was configured to "samaccountname", but could find users when reconfigured to use "sAMAccountName". LDAP is not supposed to be case-sensitive, so either should work. This appears to be a result of https://github.com/openstack/keystone/blob/12.0.0.0rc2/keystone/identity/backends/ldap/common.py#L1403 looking for that attribute in a case-sensitive manner, though there may be other places as well. found in: Pike To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1753585/+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 1741185] Re: Install and configure a compute node for Red Hat Enterprise Linux and CentOS in nova
** Also affects: rpm-packaging Importance: Undecided Status: New ** No longer affects: rpm-packaging ** Project changed: nova => rpm-packaging -- 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/1741185 Title: Install and configure a compute node for Red Hat Enterprise Linux and CentOS in nova Status in rpm-packaging: New Bug description: Error: Package: 1:openstack-nova-compute-16.0.3-2.el7.noarch (pike) Requires: qemu-kvm-rhev >= 2.9.0 To solve this problem, please install qemu-kvm-ev before install openstack-nova-compute This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 16.0.5.dev11 on 2017-12-21 19:52 SHA: ae7aef15f6ce2354443f6cce379506e4d8eefb75 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/compute-install-rdo.rst URL: https://docs.openstack.org/nova/pike/install/compute-install-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/rpm-packaging/+bug/1741185/+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 1605098] Re: Nova usage not showing server real uptime
** Project changed: nova-powervm => nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1605098 Title: Nova usage not showing server real uptime Status in OpenStack Compute (nova): New Bug description: Hi All, I am trying to calculate openstack server "uptime" where nova os usage is giving server creation time, which cant take forward for billing, Is there any way to do ? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1605098/+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 1728690] [NEW] member_role_id/name conf options reference v2
Public bug reported: The keystone v2 API has been removed, yet we still define the member_role_id and member_role_name conf options that say they are for v2. It appears that they may be used in some v3 code. That should either be modified so that these can be removed, or the help and docs for these options should be updated to explain their usage with v3. ** Affects: keystone Importance: Undecided Status: New -- 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/1728690 Title: member_role_id/name conf options reference v2 Status in OpenStack Identity (keystone): New Bug description: The keystone v2 API has been removed, yet we still define the member_role_id and member_role_name conf options that say they are for v2. It appears that they may be used in some v3 code. That should either be modified so that these can be removed, or the help and docs for these options should be updated to explain their usage with v3. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1728690/+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 1724685] [NEW] HTTP 404 creating trust with role that you don't have
Public bug reported: keystone returns HTTP 404 if you try to create a trust with a role that you don't have. This is not an appropriate error code for that case. It should be HTTP 400 (Bad Request). Found in Pike ** Affects: keystone Importance: Undecided Status: New -- 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/1724685 Title: HTTP 404 creating trust with role that you don't have Status in OpenStack Identity (keystone): New Bug description: keystone returns HTTP 404 if you try to create a trust with a role that you don't have. This is not an appropriate error code for that case. It should be HTTP 400 (Bad Request). Found in Pike To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1724685/+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 1705072] [NEW] clearing default project_id from users using wrong driver implementation
Public bug reported: https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8 #diff-271e091a68fb7b6526431423e4efe6e5 attempts to clear the default project_id for users if/when the project to which that ID belongs is deleted. However it only calls the identity driver for a single backend (the default driver from /etc/keystone/keystone.conf) instead of doing this for all backends like it should. In a multiple-backend environment, this will mean that only users in the backend using the default driver configuration will have their default project_id field cleaned up. Any users in a different backend that were using that project_id as their default would not have that appropriately cleaned up. ** Affects: keystone Importance: Undecided Status: New -- 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/1705072 Title: clearing default project_id from users using wrong driver implementation Status in OpenStack Identity (keystone): New Bug description: https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8 #diff-271e091a68fb7b6526431423e4efe6e5 attempts to clear the default project_id for users if/when the project to which that ID belongs is deleted. However it only calls the identity driver for a single backend (the default driver from /etc/keystone/keystone.conf) instead of doing this for all backends like it should. In a multiple-backend environment, this will mean that only users in the backend using the default driver configuration will have their default project_id field cleaned up. Any users in a different backend that were using that project_id as their default would not have that appropriately cleaned up. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1705072/+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 1704205] Re: GET /v3/role_assignments?effective_names API fails with unexpected 500 error
Yeah, those instructions were followed, but the problem here was that some users didn't have a value set in the property that was used for name. More specifically, the customer used a field that holds the email address as the name, and some users didn't have an email address. But even beyond that, we couldn't tell them to use a different LDAP attribute because there was no single attribute that consistently had a value for all users, even cn. You could argue that LDAP was misconfigured, but good luck getting that fixed in a large enterprise environment (which this was). You could argue that keystone was misconfigured, but in this case there was not a better LDAP attribute to use for name. So I'd like to see keystone handle this better somehow. Could keystone report a name of "" or "" or something when the attribute that is supposed to have the name is not found on a given resource? ** Changed in: keystone Status: Invalid => New -- 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/1704205 Title: GET /v3/role_assignments?effective_names API fails with unexpected 500 error Status in OpenStack Identity (keystone): New Bug description: In an environment like ldap server as identity backend, where a group has role assignment but some users in group doesn't have "name" attribute configured in ldap. So while fetching effective role assignments with include_names, it is failing in below stack trace error. 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi Traceback (most recent call last): 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 228, in __call__ 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi result = method(req, **params) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 999, in list_role_assignments_wrapper 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi return self.list_role_assignments(request) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 235, in wrapper 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi return f(self, request, filters, **kwargs) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 956, in list_role_assignments 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi return self._list_role_assignments(request, filters) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 945, in _list_role_assignments 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi include_names=include_names) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 123, in wrapped 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/core.py", line 948, in list_role_assignments 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi return self._get_names_from_role_assignments(role_assignments) 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/core.py", line 974, in _get_names_from_role_assignments 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi new_assign['user_name'] = _user['name'] 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi KeyError: 'name' 2017-07-13 05:06:10.835 10460 ERROR keystone.common.wsgi To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1704205/+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 1133435] Re: policy should return a 400 if a required field is missing
Found the problem and proposing a fix... ** Changed in: keystone Status: Expired => Confirmed ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- 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/1133435 Title: policy should return a 400 if a required field is missing Status in OpenStack Identity (keystone): In Progress Bug description: Instead, policy will return a 403 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1133435/+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 1703467] [NEW] assert_admin is checking default policy rule not admin_required
Public bug reported:
https://github.com/openstack/keystone/commit/40c118d6ba94b15d6f66da618e1d368a0f876340
broke all places calling assert_admin. Previously, assert_admin checked
the "admin_required" rule. With that change, assert_admin now checks the
"identity:admin_required" rule. That rule is not defined, so what
actually gets checked is the default rule. We must fix this before
shipping Pike to avoid breaking backward compatibility.
** Affects: keystone
Importance: Undecided
Assignee: Matthew Edmonds (edmondsw)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Matthew Edmonds (edmondsw)
--
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/1703467
Title:
assert_admin is checking default policy rule not admin_required
Status in OpenStack Identity (keystone):
New
Bug description:
https://github.com/openstack/keystone/commit/40c118d6ba94b15d6f66da618e1d368a0f876340
broke all places calling assert_admin. Previously, assert_admin
checked the "admin_required" rule. With that change, assert_admin now
checks the "identity:admin_required" rule. That rule is not defined,
so what actually gets checked is the default rule. We must fix this
before shipping Pike to avoid breaking backward compatibility.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703467/+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 1703392] [NEW] default rule no longer applies with policy in code
Public bug reported: The following should not exist in keystone/common/policies/base.py: policy.RuleDefault( name='default', check_str='rule:admin_required') because a default rule should no longer apply with policy in code. If we've correctly defined all policy rules in code, then we'll never have a case where code is checking a rule that can't be found, which is when the default rule is checked. In previous releases, some operators who override policy used the default rule to restrict all rules that they (intentionally) omitted from their policy.json. This shortened those files, and protected them if keystone added new policy checks until/unless they decided to open things up more widely. Leaving the default rule defined now that policy is in code will confuse this kind of operator (and possibly others) who haven't thought it through and realized that the default rule can't be used like that anymore because it won't be checked just because you didn't define another rule in policy.json. ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- 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/1703392 Title: default rule no longer applies with policy in code Status in OpenStack Identity (keystone): In Progress Bug description: The following should not exist in keystone/common/policies/base.py: policy.RuleDefault( name='default', check_str='rule:admin_required') because a default rule should no longer apply with policy in code. If we've correctly defined all policy rules in code, then we'll never have a case where code is checking a rule that can't be found, which is when the default rule is checked. In previous releases, some operators who override policy used the default rule to restrict all rules that they (intentionally) omitted from their policy.json. This shortened those files, and protected them if keystone added new policy checks until/unless they decided to open things up more widely. Leaving the default rule defined now that policy is in code will confuse this kind of operator (and possibly others) who haven't thought it through and realized that the default rule can't be used like that anymore because it won't be checked just because you didn't define another rule in policy.json. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703392/+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 1703369] [NEW] get_identity_providers policy should be singular
Public bug reported: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider. found in master (pike) ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- 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/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): In Progress Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider. found in master (pike) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+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 1689468] [NEW] odd keystone behavior when X-Auth-Token ends with carriage return
Public bug reported:
I had to root cause a very odd problem today, where a user complained
that they had a token that worked with neutron but didn't work with
keystone. E.g. they could list networks, but couldn't list projects. I
thought there must be some mistake, but I was finally able to reproduce
it and they were correct. Here's a script that shows the problem:
OPENSTACK=
AUTH_FILE=/root/auth.json
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'`
echo 'neutron:'; curl -1 -k -X GET https://$OPENSTACK:9696/v2.0/networks
-H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json"; echo;
echo
echo 'keystone:'; curl -1 -k -X GET https://$OPENSTACK:5000/v3/projects
-H "X-Auth-Token: $TOKEN" -H "Accept: application/json"; echo; echo
With debug=True and insecure_debug=True and
default_log_levels=keystonemiddleware=True, this yields something like:
neutron:
{"networks": []}
keystone:
{"error": {"message": "auth_context did not decode anything useful (Disable
insecure_debug mode to suppress these details.)", "code": 401, "title":
"Unauthorized"}}
I was finally able to figure out why... the awk command used to parse
the token out of the X-Subject-Token header was leaving a \r on the end
of the $TOKEN value, and apparently that's handled fine when you make
the request to neutron (and presumably any non-keystone service), but
not when you are talking to keystone directly. That makes some sense,
since keystone has to do its own token validation differently.
Changing the following line in the script above (adding the gsub to trim
the \r) fixed the issue:
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; gsub(/\r$/,"",$2);
print $2}'`
We should fix this to be consistent with non-keystone token validation, to save
someone else the trouble debugging this if nothing else. Keystone was doing
weird things, where the debug logs would show that the context knew the user
and roles, but had no token... leaving one to wonder how it figured out the
user and roles if it didn't have a token?!? Not a good user experience for
someone trying to write a script to our APIs.
** Affects: keystone
Importance: Undecided
Status: New
--
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/1689468
Title:
odd keystone behavior when X-Auth-Token ends with carriage return
Status in OpenStack Identity (keystone):
New
Bug description:
I had to root cause a very odd problem today, where a user complained
that they had a token that worked with neutron but didn't work with
keystone. E.g. they could list networks, but couldn't list projects. I
thought there must be some mistake, but I was finally able to
reproduce it and they were correct. Here's a script that shows the
problem:
OPENSTACK=
AUTH_FILE=/root/auth.json
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'`
echo 'neutron:'; curl -1 -k -X GET
https://$OPENSTACK:9696/v2.0/networks -H "X-Auth-Token: $TOKEN" -H
"Content-Type: application/json"; echo; echo
echo 'keystone:'; curl -1 -k -X GET
https://$OPENSTACK:5000/v3/projects -H "X-Auth-Token: $TOKEN" -H
"Accept: application/json"; echo; echo
With debug=True and insecure_debug=True and
default_log_levels=keystonemiddleware=True, this yields something like:
neutron:
{"networks": []}
keystone:
{"error": {"message": "auth_context did not decode anything useful (Disable
insecure_debug mode to suppress these details.)", "code": 401, "title":
"Unauthorized"}}
I was finally able to figure out why... the awk command used to parse
the token out of the X-Subject-Token header was leaving a \r on the
end of the $TOKEN value, and apparently that's handled fine when you
make the request to neutron (and presumably any non-keystone service),
but not when you are talking to keystone directly. That makes some
sense, since keystone has to do its own token validation differently.
Changing the following line in the script above (adding the gsub to
trim the \r) fixed the issue:
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":";
gsub(/\r$/,"",$2); print $2}'`
We should fix this to be consistent with non-keystone token validation, to
save someone else the trouble debugging this if nothing else. Keystone was
doing weird things, where
[Yahoo-eng-team] [Bug 1688024] [NEW] quota API missing input validation
Public bug reported:
As seen with the following curl command, neutron accepts float values
for quotas that should require ints. It coverts them to an int, but it
should have returned HTTP 400 instead. The conversion it's doing may or
may not have the same results in python3 as it does here in python2, so
that's another potential concern.
curl -s -X PUT
http://localhost:9696/v2.0/quotas/c4d15a1adc0a4cd89006d4db0a2bdfed -H "Accept:
application/json" -H "X-Auth-Token: " -H "Content-Type:
application/json" -d '{"quota": {"floatingip": 2.9}}' | python -m json.tool
{
"quota": {
"floatingip": 2,
"network": -1,
"port": -1,
"rbac_policy": 10,
"router": 10,
"security_group": 10,
"security_group_rule": 100,
"subnet": -1,
"subnetpool": -1
}
}
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1688024
Title:
quota API missing input validation
Status in neutron:
New
Bug description:
As seen with the following curl command, neutron accepts float values
for quotas that should require ints. It coverts them to an int, but it
should have returned HTTP 400 instead. The conversion it's doing may
or may not have the same results in python3 as it does here in
python2, so that's another potential concern.
curl -s -X PUT
http://localhost:9696/v2.0/quotas/c4d15a1adc0a4cd89006d4db0a2bdfed -H "Accept:
application/json" -H "X-Auth-Token: " -H "Content-Type:
application/json" -d '{"quota": {"floatingip": 2.9}}' | python -m json.tool
{
"quota": {
"floatingip": 2,
"network": -1,
"port": -1,
"rbac_policy": 10,
"router": 10,
"security_group": 10,
"security_group_rule": 100,
"subnet": -1,
"subnetpool": -1
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1688024/+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 1684994] Re: POST v3/auth/tokens API is returning unexpected 500 error when ldap credentials are incorrect
I don't think this is totally invalid. It's right to return a 500, but I
think we could improve the error message that goes with that. I.e., add
code to raise LDAPServerConnectionError once the bug Breton opened in
comment 6 is addressed.
** Changed in: keystone
Status: Invalid => New
--
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/1684994
Title:
POST v3/auth/tokens API is returning unexpected 500 error when ldap
credentials are incorrect
Status in OpenStack Identity (keystone):
New
Bug description:
When keystone is configured with ldap server as identity backend, if
incorrect credentials were configured under [ldap] section [1] of domains conf
file, then POST request on /v3/auth/tokens API with users in ldap is returning
unexpected 500 error [0] with stacktrace[2] shown below.
Instead of unexpected error user should be given a proper message about
invalid credentials configured.
[0]
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server Error"}}
[1]
[ldap]
url = ldap://9.9.9.9
user = cn=root
password = <>
[2]Stacktrace:
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi
[req-7b62d1db-64bd-4961-819e-0815bc355636
02b49a455f5c9d9561881683c0f09919c5ab38a6eeed6de5c4ae3523df2dc706
36b96caa022742a1b74692b29bd044a7 - 3ae481350a504cbdaf35e18b8753d002
3ae481350a504cbdaf35e18b8753d002] {'desc': 'Invalid credentials'}
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi Traceback (most
recent call last):
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 228, in
__call__
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi result =
method(req, **params)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 235, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
request, filters, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/controllers.py", line 230,
in list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi refs =
self.identity_api.list_users(domain_scope=domain, hints=hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 123, in
wrapped
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi __ret_val =
__f(*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 413, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 423, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 1027, in
list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi ref_list =
self._handle_federated_attributes_in_hints(driver, hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 1010, in
_handle_federated_attributes_in_hints
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
driver.list_users(hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 88, in list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
self.user.get_all_filtered(hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 353, in get_all_filtered
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi for user in
self.get_all(query, hints)]
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 345, in get_all
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi hints=hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py",
line 1872, in get_all
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
super(EnabledEmuMixIn, self).get_all(ldap_filter, hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
[Yahoo-eng-team] [Bug 1684994] Re: POST v3/auth/tokens API is returning unexpected 500 error when ldap credentials are incorrect
That I would agree with.
** Changed in: keystone
Status: Invalid => New
--
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/1684994
Title:
POST v3/auth/tokens API is returning unexpected 500 error when ldap
credentials are incorrect
Status in OpenStack Identity (keystone):
New
Bug description:
When keystone is configured with ldap server as identity backend, if
incorrect credentials were configured under [ldap] section [1] of domains conf
file, then POST request on /v3/auth/tokens API with users in ldap is returning
unexpected 500 error [0] with stacktrace[2] shown below.
Instead of unexpected error user should be given a proper message about
invalid credentials configured.
[0]
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server Error"}}
[1]
[ldap]
url = ldap://9.9.9.9
user = cn=root
password = <>
[2]Stacktrace:
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi
[req-7b62d1db-64bd-4961-819e-0815bc355636
02b49a455f5c9d9561881683c0f09919c5ab38a6eeed6de5c4ae3523df2dc706
36b96caa022742a1b74692b29bd044a7 - 3ae481350a504cbdaf35e18b8753d002
3ae481350a504cbdaf35e18b8753d002] {'desc': 'Invalid credentials'}
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi Traceback (most
recent call last):
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 228, in
__call__
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi result =
method(req, **params)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 235, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
request, filters, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/controllers.py", line 230,
in list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi refs =
self.identity_api.list_users(domain_scope=domain, hints=hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 123, in
wrapped
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi __ret_val =
__f(*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 413, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 423, in
wrapper
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return f(self,
*args, **kwargs)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 1027, in
list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi ref_list =
self._handle_federated_attributes_in_hints(driver, hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 1010, in
_handle_federated_attributes_in_hints
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
driver.list_users(hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 88, in list_users
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
self.user.get_all_filtered(hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 353, in get_all_filtered
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi for user in
self.get_all(query, hints)]
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/core.py",
line 345, in get_all
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi hints=hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py",
line 1872, in get_all
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi return
super(EnabledEmuMixIn, self).get_all(ldap_filter, hints)
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py",
line 1518, in get_all
2017-04-20 09:09:08.304 12300 ERROR keystone.common.wsgi for x in
self._ldap_get_all(hints, ldap_filter)]
2017-04-20 09:09:08.304 12300 ERROR
[Yahoo-eng-team] [Bug 1675486] [NEW] network:attach_external_network policy check outside nova-api
Public bug reported: The "network:attach_external_network" policy is being checked in nova- compute rather than in nova-api. 1) Only the api process should be doing policy checks. 2) Someone who wants to override policy for this would have to put a policy.json file on each host, which is certainly problematic. 3) There's talk of splitting nova-compute out of nova into its own project, which obviously shouldn't rely on nova's policy file. This apparently came up on the mailing list [1] a while ago, but it doesn't seem like anything has been done about it so far. Still this way in master. See that mailing list thread for much more information and talk of possible solutions. johnthetubaguy also noted via irc [2] that the neutron refactor work is heading in a direction that may fix this. [1] https://openstack.nimeyo.com/87011/openstack-policy-check-network-attach_external_network [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-23.log.html#t2017-03-23T16:24:39 ** Affects: nova Importance: Low Status: Confirmed ** Tags: network policy -- 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/1675486 Title: network:attach_external_network policy check outside nova-api Status in OpenStack Compute (nova): Confirmed Bug description: The "network:attach_external_network" policy is being checked in nova- compute rather than in nova-api. 1) Only the api process should be doing policy checks. 2) Someone who wants to override policy for this would have to put a policy.json file on each host, which is certainly problematic. 3) There's talk of splitting nova-compute out of nova into its own project, which obviously shouldn't rely on nova's policy file. This apparently came up on the mailing list [1] a while ago, but it doesn't seem like anything has been done about it so far. Still this way in master. See that mailing list thread for much more information and talk of possible solutions. johnthetubaguy also noted via irc [2] that the neutron refactor work is heading in a direction that may fix this. [1] https://openstack.nimeyo.com/87011/openstack-policy-check-network-attach_external_network [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-23.log.html#t2017-03-23T16:24:39 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1675486/+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 1632820] Re: os-server-groups policy doesn't separate CRUD actions
*** This bug is a duplicate of bug 1636157 *** https://bugs.launchpad.net/bugs/1636157 ** This bug has been marked a duplicate of bug 1636157 os-server-groups uses same policy.json rule for all CRUD operations -- 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/1632820 Title: os-server-groups policy doesn't separate CRUD actions Status in OpenStack Compute (nova): Opinion Bug description: nova.api.openstack.compute.server_groups.ServerGroupController uses the same policy check (os_compute_api:os-server-groups) for show, delete, index, and create, instead of separating these into separate checks (e.g. os_compute_api:os-server-groups:delete). This makes it impossible to customize policy such that some roles are allowed to do some but not all of these operations, E.g. show/index server groups but not create/delete them. Found with Newton. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632820/+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 1639230] [NEW] reschedule fails with ip already allocated error
2308-48ab-9101-0d48721c9fd2 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] Neutron server returns request_ids: ['req-682b2d6b-768f-413d-862c-32490cad5589'] 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] found in newton ** Affects: nova Importance: Undecided Assignee: Matthew Edmonds (edmondsw) 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/1639230 Title: reschedule fails with ip already allocated error Status in OpenStack Compute (nova): New Bug description: Tried to create a server in a multi-host environment. The create failed on the first host that was attempted due to a ClientException raised by nova.volume.cinder.API.initialize_connection while trying to attach a volume. When the build was rescheduled on a different host, it should have realized that the network was already allocated by the first attempt and reused that, but the network_allocated=True from instance.system_metadata somehow disappeared, leading to the following exception that causes the reschedule to fail: 2016-10-13 04:48:29.007 16273 WARNING nova.network.neutronv2.api [req-9b343ef7-e8d9-4a61-b86c-a61908afe4df 0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9 94e1baed634145e0aade858973ae88e8 - - -] [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] Neutron error creating port on network 5038a36b-cb1e-4a61-b26c-a05a80b37ed6 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] Traceback (most recent call last): 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 392, in _create_port_minimal 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] port_response = port_client.create_port(port_req_body) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 98, in wrapper 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] ret = obj(*args, **kwargs) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 750, in create_port 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] return self.post(self.ports_path, body=body) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 98, in wrapper 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] ret = obj(*args, **kwargs) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 365, in post 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] headers=headers, params=params) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 98, in wrapper 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] ret = obj(*args, **kwargs) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 300, in do_request 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] self._handle_fault_response(status_code, replybody, resp) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 98, in wrapper 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] ret = obj(*args, **kwargs) 2016-10-13 04:48:29.007 16273 ERROR nova.network.neutronv2.api [instance: b85d6c6c-e385-4601-aa47-5c580f893c9b] File "/usr/lib/python2.7/site-packa
[Yahoo-eng-team] [Bug 1632820] [NEW] os-server-groups policy doesn't separate CRUD actions
Public bug reported: nova.api.openstack.compute.server_groups.ServerGroupController uses the same policy check (os_compute_api:os-server-groups) for show, delete, index, and create, instead of separating these into separate checks (e.g. os_compute_api:os-server-groups:delete). This makes it impossible to customize policy such that some roles are allowed to do some but not all of these operations, E.g. show/index server groups but not create/delete them. Found with Newton. ** 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/1632820 Title: os-server-groups policy doesn't separate CRUD actions Status in OpenStack Compute (nova): New Bug description: nova.api.openstack.compute.server_groups.ServerGroupController uses the same policy check (os_compute_api:os-server-groups) for show, delete, index, and create, instead of separating these into separate checks (e.g. os_compute_api:os-server-groups:delete). This makes it impossible to customize policy such that some roles are allowed to do some but not all of these operations, E.g. show/index server groups but not create/delete them. Found with Newton. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632820/+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 1602854] [NEW] API documentation missing query parameters
Public bug reported: the API documentation is missing any mention of what query parameters are allowed for various APIs and how they work. E.g., it should mention the "scope.project.id" query parameter for v3/role_assignments, as used by `openstack user list --project `. ** Affects: keystone Importance: Undecided Status: New -- 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/1602854 Title: API documentation missing query parameters Status in OpenStack Identity (keystone): New Bug description: the API documentation is missing any mention of what query parameters are allowed for various APIs and how they work. E.g., it should mention the "scope.project.id" query parameter for v3/role_assignments, as used by `openstack user list --project `. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1602854/+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 1602396] Re: GET os-quota-class-sets/{anything} returns OK
same issue found in nova as well as cinder
** Also affects: nova
Importance: Undecided
Status: New
** Description changed:
I don't quite understand what a quota class set is, since there is no
- documentation (see https://bugs.launchpad.net/cinder/+bug/1415214), but
+ documentation (see https://bugs.launchpad.net/cinder/+bug/1602400), but
no matter what it is the API isn't working properly... You have to
specify a class set, but any name you give is accepted, with the only
difference in the response being that the "id" returns back whatever
name you gave. Surely class sets with these names don't actually exist
and the API should be returning an error.
E.g. where class set is "g":
# curl
http://localhost:9000/v2/67154cb74e9a45b19423d164f180e2db/os-quota-class-sets/g
-H "Accept: application/json" -H "X-Auth-Token:
e21820a0fc1147f9baa58fcb08243aa8"; echo
{"quota_class_set": {"per_volume_gigabytes": -1, "gigabytes_svc186 base
template": 100, "volumes": 10, "snapshots_svc186 base template":
10, "gigabytes": 100, "backup_gigabytes": 1000, "snapshots": 10,
"volumes_svc186 base template": 10, "backups": 10, "id": "g"}}
E.g. where class set is "x":
# curl
http://localhost:9000/v2/67154cb74e9a45b19423d164f180e2db/os-quota-class-sets/x
-H "Accept: application/json" -H "X-Auth-Token:
e21820a0fc1147f9baa58fcb08243aa8"; echo
{"quota_class_set": {"per_volume_gigabytes": -1, "gigabytes_svc186 base
template": 100, "volumes": 10, "snapshots_svc186 base template":
10, "gigabytes": 100, "backup_gigabytes": 1000, "snapshots": 10,
"volumes_svc186 base template": 10, "backups": 10, "id": "x"}}
** Tags added: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1602396
Title:
GET os-quota-class-sets/{anything} returns OK
Status in Cinder:
New
Status in OpenStack Compute (nova):
New
Bug description:
I don't quite understand what a quota class set is, since there is no
documentation (see https://bugs.launchpad.net/cinder/+bug/1602400),
but no matter what it is the API isn't working properly... You have to
specify a class set, but any name you give is accepted, with the only
difference in the response being that the "id" returns back whatever
name you gave. Surely class sets with these names don't actually exist
and the API should be returning an error.
E.g. where class set is "g":
# curl
http://localhost:9000/v2/67154cb74e9a45b19423d164f180e2db/os-quota-class-sets/g
-H "Accept: application/json" -H "X-Auth-Token:
e21820a0fc1147f9baa58fcb08243aa8"; echo
{"quota_class_set": {"per_volume_gigabytes": -1, "gigabytes_svc186 base
template": 100, "volumes": 10, "snapshots_svc186 base template":
10, "gigabytes": 100, "backup_gigabytes": 1000, "snapshots": 10,
"volumes_svc186 base template": 10, "backups": 10, "id": "g"}}
E.g. where class set is "x":
# curl
http://localhost:9000/v2/67154cb74e9a45b19423d164f180e2db/os-quota-class-sets/x
-H "Accept: application/json" -H "X-Auth-Token:
e21820a0fc1147f9baa58fcb08243aa8"; echo
{"quota_class_set": {"per_volume_gigabytes": -1, "gigabytes_svc186 base
template": 100, "volumes": 10, "snapshots_svc186 base template":
10, "gigabytes": 100, "backup_gigabytes": 1000, "snapshots": 10,
"volumes_svc186 base template": 10, "backups": 10, "id": "x"}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1602396/+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 1602400] [NEW] os-quota-class-sets APIs are undocumented
Public bug reported: http://developer.openstack.org/api-ref does not document the os-quota- class-sets APIs for either nova or cinder. ** Affects: cinder Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Tags: api-ref ** Also affects: cinder Importance: Undecided Status: New ** Tags added: api-ref -- 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/1602400 Title: os-quota-class-sets APIs are undocumented Status in Cinder: New Status in OpenStack Compute (nova): New Bug description: http://developer.openstack.org/api-ref does not document the os-quota- class-sets APIs for either nova or cinder. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602400/+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 1590584] [NEW] ldap delete_user fails to cleanup all group membership
Public bug reported: When an LDAP user is deleted, keystone removes it from groups that match the group_filter conf setting, but fails to remove it from any other groups. It should remove it from all groups. ** Affects: keystone Importance: Undecided Status: New -- 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/1590584 Title: ldap delete_user fails to cleanup all group membership Status in OpenStack Identity (keystone): New Bug description: When an LDAP user is deleted, keystone removes it from groups that match the group_filter conf setting, but fails to remove it from any other groups. It should remove it from all groups. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1590584/+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 1588927] [NEW] /v3/groups?name= bypasses group_filter for LDAP
Public bug reported: The same problem reported and fixed for users as https://bugs.launchpad.net/keystone/+bug/1577804 also exists for groups. ** Affects: keystone Importance: Undecided Status: New ** Tags: mitaka-backport-potential ** Tags added: mitaka-backport-potential -- 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/1588927 Title: /v3/groups?name= bypasses group_filter for LDAP Status in OpenStack Identity (keystone): New Bug description: The same problem reported and fixed for users as https://bugs.launchpad.net/keystone/+bug/1577804 also exists for groups. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1588927/+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 1580338] [NEW] create token API is not doing proper input validation
Public bug reported:
HTTP 500 being returned when the request body for POST /v3/auth/tokens
has an empty string in place of one of the dicts that should be passed
in. This shows that the code is not doing proper input validation. It
should detect the user error and return an HTTP 400. Here's an example
where project domain is "" instead of {"id": "default"}:
# curl -1 -k -i -X POST https://localhost:5000/v3/auth/tokens -H "Accept:
application/json" -H "Content-Type: application/json" -d '{"auth": {"scope":
{"project": {"name": "myproj", "domain": ""}}, "identity": {"methods":
["password"], "password": {"user": {"domain": {"name": "Default"}, "name":
"myuser", "password": "mypassword"}'
HTTP/1.1 500 Internal Server Error
Date: Tue, 10 May 2016 20:39:53 GMT
Server: Apache
Vary: X-Auth-Token
x-openstack-request-id: req-a4961a66-b545-407e-9aa3-7575e38c252c
Content-Length: 143
Connection: close
Content-Type: application/json
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
Logs show:
2016-05-10 16:39:53.716 2951 INFO keystone.common.wsgi
[req-a4961a66-b545-407e-9aa3-7575e38c252c - - - - -] POST
https://localhost:5000/v3/auth/tokens
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi
[req-a4961a66-b545-407e-9aa3-7575e38c252c - - - - -] 'unicode' object has no
attribute 'get'
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi Traceback (most recent
call last):
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 249, in
__call__
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi result =
method(context, **params)
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 392, in
authenticate_for_token
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi auth_info =
AuthInfo.create(context, auth=auth)
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 137, in
create
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi
auth_info._validate_and_normalize_auth_data(scope_only)
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 305, in
_validate_and_normalize_auth_data
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi
self._validate_and_normalize_scope_data()
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 247, in
_validate_and_normalize_scope_data
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi project_ref =
self._lookup_project(self.auth['scope']['project'])
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 210, in
_lookup_project
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi domain_ref =
self._lookup_domain(project_info['domain'])
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 172, in
_lookup_domain
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi domain_id =
domain_info.get('id')
2016-05-10 16:39:53.717 2951 ERROR keystone.common.wsgi AttributeError:
'unicode' object has no attribute 'get'
Note: you can also get HTTP 500 if you replace other dicts in the
request, e.g. {"user": ""}
** Affects: keystone
Importance: Undecided
Status: New
--
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/1580338
Title:
create token API is not doing proper input validation
Status in OpenStack Identity (keystone):
New
Bug description:
HTTP 500 being returned when the request body for POST /v3/auth/tokens
has an empty string in place of one of the dicts that should be passed
in. This shows that the code is not doing proper input validation. It
should detect the user error and return an HTTP 400. Here's an example
where project domain is "" instead of {"id": "default"}:
# curl -1 -k -i -X POST https://localhost:5000/v3/auth/tokens -H "Accept:
application/json" -H "Content-Type: application/json" -d '{"auth": {"scope":
{"project": {"name": "myproj", "domain": ""}}, "identity": {"methods":
["password"], "password": {"user": {"domain": {"name": "Default"}, "name":
"myuser", "password": "mypassword"}'
HTTP/1.1 500 Internal Server Error
Date: Tue, 10 May 2016 20:39:53 GMT
Server: Apache
Vary: X-Auth-Token
x-openstack-request-id: req-a4961a66-b545-407e-9aa3-7575e38c252c
Content-Length: 143
Connection: close
Content-Type: application/json
{"error": {"message": "An unexpected error prevented
[Yahoo-eng-team] [Bug 1577804] [NEW] /v3/users?name= bypasses user_filter for LDAP
Public bug reported: using the LDAP driver with user_filter, a GET /v3/users?name= returns users that do not match the filter. e.g.: user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr)) # openstack user list ++-+ | ID | Name| ++-+ | 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin | | 42 | | | 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | arc1_stgmgr | | b2 | | ++-+ # openstack user show arc1_dep +---+--+ | Field | Value| +---+--+ | domain_id | default | | id| 631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 | | name | arc1_dep | +---+--+ ** Affects: keystone Importance: Undecided Status: New -- 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/1577804 Title: /v3/users?name= bypasses user_filter for LDAP Status in OpenStack Identity (keystone): New Bug description: using the LDAP driver with user_filter, a GET /v3/users?name= returns users that do not match the filter. e.g.: user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr)) # openstack user list ++-+ | ID | Name | ++-+ | 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin | | 42 | | | 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | arc1_stgmgr | | b2 | | ++-+ # openstack user show arc1_dep +---+--+ | Field | Value | +---+--+ | domain_id | default | | id| 631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 | | name | arc1_dep | +---+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1577804/+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 1565108] [NEW] "unexpected error" attempting to rename a project when name is already in use
Public bug reported:
When a user attempts to rename a project via the PATCH
v3/projects/{project_id} API, and the new name is already in-use, rather
than return a nice error explaining that the name is in use, keystone
blows up and returns an HTTP 500:
# curl -k -1 -i -X PATCH
https://localhost:5000/v3/projects/e4e12eb216ca471cb2646bcdbdcc3ddc -H
"User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H
"Accept: application/json" -H "X-Auth-Token: 04a2539bb3144af6867d8c7e50b15607"
-d '{"project": {"name": "Project_B"}}'
HTTP/1.1 500 Internal Server Error
Date: Fri, 01 Apr 2016 21:42:50 GMT
Server: Apache
Vary: X-Auth-Token
x-openstack-request-id: req-8d9904e7-5775-42ec-8fc5-773f7f38cbf2
Content-Length: 143
Connection: close
Content-Type: application/json
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
** Affects: keystone
Importance: Undecided
Status: New
--
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/1565108
Title:
"unexpected error" attempting to rename a project when name is already
in use
Status in OpenStack Identity (keystone):
New
Bug description:
When a user attempts to rename a project via the PATCH
v3/projects/{project_id} API, and the new name is already in-use,
rather than return a nice error explaining that the name is in use,
keystone blows up and returns an HTTP 500:
# curl -k -1 -i -X PATCH
https://localhost:5000/v3/projects/e4e12eb216ca471cb2646bcdbdcc3ddc -H
"User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H
"Accept: application/json" -H "X-Auth-Token: 04a2539bb3144af6867d8c7e50b15607"
-d '{"project": {"name": "Project_B"}}'
HTTP/1.1 500 Internal Server Error
Date: Fri, 01 Apr 2016 21:42:50 GMT
Server: Apache
Vary: X-Auth-Token
x-openstack-request-id: req-8d9904e7-5775-42ec-8fc5-773f7f38cbf2
Content-Length: 143
Connection: close
Content-Type: application/json
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1565108/+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 1558690] [NEW] project set works for invalid properties
Public bug reported: openstack project set accepts invalid properties, and even somehow sets their values # openstack project set ABC --property xyz=pqr # openstack project show ABC +-+--+ | Field | Value| +-+--+ | description | | | domain_id | ef8acb82bebd4c4abdc6b2056440b596 | | enabled | True | | id | 315700c2a1384b1ca21543504e3513bb | | is_domain | False| | name| ABC | | xyz | pqr | +-+--+ As seen above, the new "xyz" field was created with the specified value. This is not a valid property and should not have been created. Also, specifying an invalid property without a value did not return an error: # openstack project set ABC --property QQQ # openstack project show ABC +-+--+ | Field | Value| +-+--+ | description | | | domain_id | ef8acb82bebd4c4abdc6b2056440b596 | | enabled | True | | id | 315700c2a1384b1ca21543504e3513bb | | is_domain | False| | name| ABC | | xyz | pqr | +-+--+ ** Affects: keystone Importance: Undecided Status: New ** Affects: python-openstackclient Importance: Undecided Status: New ** Also affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1558690 Title: project set works for invalid properties Status in OpenStack Identity (keystone): New Status in python-openstackclient: New Bug description: openstack project set accepts invalid properties, and even somehow sets their values # openstack project set ABC --property xyz=pqr # openstack project show ABC +-+--+ | Field | Value| +-+--+ | description | | | domain_id | ef8acb82bebd4c4abdc6b2056440b596 | | enabled | True | | id | 315700c2a1384b1ca21543504e3513bb | | is_domain | False| | name| ABC | | xyz | pqr | +-+--+ As seen above, the new "xyz" field was created with the specified value. This is not a valid property and should not have been created. Also, specifying an invalid property without a value did not return an error: # openstack project set ABC --property QQQ # openstack project show ABC +-+--+ | Field | Value| +-+--+ | description | | | domain_id | ef8acb82bebd4c4abdc6b2056440b596 | | enabled | True | | id | 315700c2a1384b1ca21543504e3513bb | | is_domain | False| | name| ABC | | xyz | pqr | +-+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1558690/+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 1553224] [NEW] keystone-manage bootstrap assumes user-project role assignment
Public bug reported: keystone-manage bootstrap creates a role assignment for the specified user on the specified project. That is one way someone might want to do bootstrapping, but there are good reasons a user may need/prefer: 1) user-domain role assignment... e.g. Switching identity drivers for an existing single-domain multi-project configuration. Bootstrapping is needed to configure the initial role assignments for the new driver. Since the "cloud admin" concept is not essential for single-domain environments, it may very well not be configured, yet the initial role assignment needs to grant someone the ability to create additional role assignments for all projects in the domain. This would be a domain admin. 2) group-project role assignment... e.g. Where the desired end result is for a group-project role assignment on the cloud admin project, it makes more sense to allow that to be created directly (which could be done without even knowing the password of any user in that group) than to require bootstrapping of a single user and then using their account to create the group assignment and delete the bootstrapped assignment. 3) group-domain role assignment... e.g. combination of #1 and #2 ** Affects: keystone Importance: Undecided Status: New -- 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/1553224 Title: keystone-manage bootstrap assumes user-project role assignment Status in OpenStack Identity (keystone): New Bug description: keystone-manage bootstrap creates a role assignment for the specified user on the specified project. That is one way someone might want to do bootstrapping, but there are good reasons a user may need/prefer: 1) user-domain role assignment... e.g. Switching identity drivers for an existing single-domain multi-project configuration. Bootstrapping is needed to configure the initial role assignments for the new driver. Since the "cloud admin" concept is not essential for single- domain environments, it may very well not be configured, yet the initial role assignment needs to grant someone the ability to create additional role assignments for all projects in the domain. This would be a domain admin. 2) group-project role assignment... e.g. Where the desired end result is for a group-project role assignment on the cloud admin project, it makes more sense to allow that to be created directly (which could be done without even knowing the password of any user in that group) than to require bootstrapping of a single user and then using their account to create the group assignment and delete the bootstrapped assignment. 3) group-domain role assignment... e.g. combination of #1 and #2 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1553224/+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 1553216] [NEW] keystone-manage bootstrap does not work for non-SQL identity drivers
Public bug reported: keystone-manage bootstrap attempts to create the specified user and then handles a Conflict error as notice that the user already exists. This works for the default SQL identity driver, but does not work for drivers that do not support creating users. In order to work for all drivers, which is necessary to support role assignment bootstrapping whenever the driver configuration is changed, it should attempt to GET the user or otherwise check in a way that will work for drivers that do not support user creation. ** Affects: keystone Importance: Undecided Status: New -- 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/1553216 Title: keystone-manage bootstrap does not work for non-SQL identity drivers Status in OpenStack Identity (keystone): New Bug description: keystone-manage bootstrap attempts to create the specified user and then handles a Conflict error as notice that the user already exists. This works for the default SQL identity driver, but does not work for drivers that do not support creating users. In order to work for all drivers, which is necessary to support role assignment bootstrapping whenever the driver configuration is changed, it should attempt to GET the user or otherwise check in a way that will work for drivers that do not support user creation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1553216/+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 1542024] Re: keystoneauth1.access.service_catalog.ServiceCatalog is missing factory method
looks like this was removed by https://github.com/openstack/keystoneauth/commit/473b70566a88ce84967654e5fc2dd87e04538fb9 The assumption there is that nobody would ever go to the ServiceCatalog directly, but unfortunately nova does. This issue was found when we were looking at https://github.com/openstack/nova/blob/f19ddc4c507dfc64e4d7f930caefab5a5e1680b8/nova/context.py#L50 and trying to see how to update that not to be specific to keystone v2. Maybe you have an alternative suggestion on how to fix nova, Jamie? ** Project changed: keystone => keystoneauth -- 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/1542024 Title: keystoneauth1.access.service_catalog.ServiceCatalog is missing factory method Status in keystoneauth: New Bug description: The file keystoneauth1.access.service_catalog.ServiceCatalog is missing a factory() method equivalent to the factory() method provided by keystoneclient.service_catalog.ServiceCatalog.factory(). This method allows for creation of a ServiceCatalog object without knowing the specific API version in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1542024/+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 1505777] [NEW] inconsistent support for optional dependencies
Public bug reported: keystone's requirements.txt includes several things that are really optional dependencies, only needed if you are using certain features. These should be moved out of requirements.txt and handled as extras in setup.cfg. A few of these that I've noticed are: passlib (only needed for the sql identity backend) oauthlib pysaml2 This is already done for several things: python-ldap ldappool python-memcached pymongo bandit We ought to be consistent. Moving optional dependencies to setup.cfg is both a) correct and b) will allow those who do not need certain features to package/ship/install less. This is important for applications based on OpenStack that don't want the extra work of building/shipping/installing/supporting things which are not necessary for their application. It's important for users that shouldn't have to install things they don't need. Etc. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1505777 Title: inconsistent support for optional dependencies Status in Keystone: New Bug description: keystone's requirements.txt includes several things that are really optional dependencies, only needed if you are using certain features. These should be moved out of requirements.txt and handled as extras in setup.cfg. A few of these that I've noticed are: passlib (only needed for the sql identity backend) oauthlib pysaml2 This is already done for several things: python-ldap ldappool python-memcached pymongo bandit We ought to be consistent. Moving optional dependencies to setup.cfg is both a) correct and b) will allow those who do not need certain features to package/ship/install less. This is important for applications based on OpenStack that don't want the extra work of building/shipping/installing/supporting things which are not necessary for their application. It's important for users that shouldn't have to install things they don't need. Etc. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1505777/+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 1504312] [NEW] bad deprecation warning for "Registering resources to apply quota limits"
Public bug reported: The following deprecation warning appears to be logged in all cases, regardless of neutron or other configuration. 2015-09-18 10:59:40.472 20552 WARNING neutron.quota [-] Deprecated: Registering resources to apply quota limits to using the quota_items option is deprecated as of Liberty.Resource REST controllers should take care of registering resources with the quota engine. That should only be printed when things are configured/working in a way that we now want to deprecate... not always. Found with Liberty. ** 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/1504312 Title: bad deprecation warning for "Registering resources to apply quota limits" Status in neutron: New Bug description: The following deprecation warning appears to be logged in all cases, regardless of neutron or other configuration. 2015-09-18 10:59:40.472 20552 WARNING neutron.quota [-] Deprecated: Registering resources to apply quota limits to using the quota_items option is deprecated as of Liberty.Resource REST controllers should take care of registering resources with the quota engine. That should only be printed when things are configured/working in a way that we now want to deprecate... not always. Found with Liberty. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1504312/+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 1486087] [NEW] deprecated neutron_opts usage not logging warnings
Public bug reported: nova.network.neutronv2.api.neutron_opts almost all say in their help that they are deprecated, but that's not the correct way to deprecate things. Because deprecated_for_removal was not used, usage of these options is not resulting in appropriate log warnings. Found on master. ** Affects: nova Importance: Medium Assignee: Cale Rath (ctrath) Status: Confirmed ** Tags: network neutron -- 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/1486087 Title: deprecated neutron_opts usage not logging warnings Status in OpenStack Compute (nova): Confirmed Bug description: nova.network.neutronv2.api.neutron_opts almost all say in their help that they are deprecated, but that's not the correct way to deprecate things. Because deprecated_for_removal was not used, usage of these options is not resulting in appropriate log warnings. Found on master. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1486087/+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 1475737] [NEW] requirements.txt includes unnecessary oslo.vmware
Public bug reported: olso_vmware is not referenced in glance python code, yet requirements.txt includes it. This should either be removed from requirements entirely, or moved to test-requirements. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1475737 Title: requirements.txt includes unnecessary oslo.vmware Status in Glance: New Bug description: olso_vmware is not referenced in glance python code, yet requirements.txt includes it. This should either be removed from requirements entirely, or moved to test-requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1475737/+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 1431652] Re: os-volume_attachments return 500 error code instead of 404 if invalid volume is specified
** Project changed: nova = python-cinderclient ** Changed in: python-cinderclient Status: Invalid = Confirmed -- 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/1431652 Title: os-volume_attachments return 500 error code instead of 404 if invalid volume is specified Status in Python client library for Cinder: Confirmed Bug description: If I do a DELETE of os-volume_attachments with invalid volume, 500 error code is being returned instead of 404. The problem is at volume = self.volume_api.get(context, volume_id) where NotFound exception is not being handled. This problem is fixed in v3 API. 2015-03-12 08:49:19.146 20273 INFO nova.osapi_compute.wsgi.server [req-001f6e6e-4726-4738-a3e7-74c5c7eaaac5 None] 9.114.193.249,127.0.0.1 DELETE /v2/dd069270f6634cafaf66777c4a2ee137/servers/e44ee780-0b57-4bcb-89ef-ab99e4d7d1a0/os-volume_attachments/volume-815308985 HTTP/1.1 status: 500 len: 295 time: 0.6408780 ... 2015-03-12 08:49:18.969 20273 ERROR nova.api.openstack [req-001f6e6e-4726-4738-a3e7-74c5c7eaaac5 None] Caught error: Not Found (HTTP 404) (Request-ID: req-8d133de9-430e-41ad-819a-3f9685deed29) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack Traceback (most recent call last): 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/nova/api/openstack/__init__.py, line 125, in __call__ 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return req.get_response(self.application) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/webob/request.py, line 1296, in send 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack application, catch_exc_info=False) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/webob/request.py, line 1260, in call_application 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return resp(environ, start_response) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py, line 748, in __call__ 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return self._call_app(env, start_response) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py, line 684, in _call_app 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return self._app(env, _fake_start_response) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ ... 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/nova/api/openstack/compute/contrib/volumes.py, line 398, in delete 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack volume = self.volume_api.get(context, volume_id) ... 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack item = cinder.cinderclient(context).volumes.get(volume_id) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/cinderclient/v2/volumes.py, line 227, in get 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return self._get(/volumes/%s % volume_id, volume) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/cinderclient/base.py, line 149, in _get 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack resp, body = self.api.client.get(url) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 88, in get 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return self._cs_request(url, 'GET', **kwargs) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 85, in _cs_request 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return self.request(url, method, **kwargs) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 80, in request 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack return super(SessionClient, self).request(*args, **kwargs) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack File /usr/lib/python2.7/site-packages/keystoneclient/adapter.py, line 166, in request 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack resp = super(LegacyJsonAdapter, self).request(*args, **kwargs) 2015-03-12 08:49:18.969 20273 TRACE nova.api.openstack
[Yahoo-eng-team] [Bug 1435855] Re: Default rule does not work in ceilometer policy.json
** Also affects: ceilometer
Importance: Undecided
Status: New
** No longer affects: ceilometer
** Project changed: keystone = ceilometer
** Changed in: ceilometer
Status: Incomplete = New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1435855
Title:
Default rule does not work in ceilometer policy.json
Status in OpenStack Telemetry (Ceilometer):
In Progress
Bug description:
The rule default does not work for ceilometer. I tried with few of
these and they don't work. I am able to proceed with the REST apis
that are not mentioned even when the default is set to not_allowed.
default: not_allowed:True,
default: !,
The problem appears to be here /usr/lib/python2.7/site-
packages/ceilometer/api/rbac.py
for rule_name in _ENFORCER.rules.keys():
if rule_method == rule_name:
if not _ENFORCER.enforce(
rule_name,
{},
policy_dict):
pecan.core.abort(status_code=403,
detail='RBAC Authorization Failed')
The rbac.enforce method loops through all the rules and filters the one that
matches the one requested for. However , in a case where the rule has not been
specified in the policy.json file , there is no logic in the above to fall back
on the default value. The default logic is already taken case of by oslo_policy
and the above loop seems to be causing the problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1435855/+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 1421863] Re: Can not find policy directory: policy.d spams the logs
** Also affects: cinder Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1421863 Title: Can not find policy directory: policy.d spams the logs Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in Cinder: New Status in devstack - openstack dev environments: In Progress Status in OpenStack Compute (Nova): Fix Committed Status in The Oslo library incubator: Triaged Status in Oslo Policy: Fix Released Bug description: This hits over 118 million times in 24 hours in Jenkins runs: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiQ2FuIG5vdCBmaW5kIHBvbGljeSBkaXJlY3Rvcnk6IHBvbGljeS5kXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6Ijg2NDAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMzg2Njk0MTcxOH0= We can probably just change something in devstack to avoid this. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1421863/+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 1431015] [NEW] v3/users or groups calls not working without domain_id
Public bug reported:
The keystone.common.controller._get_domain_id_for_list_request comment says the
below:
Get the domain_id for a v3 list call.
If we running with multiple domain drivers, then the caller must
specify a domain_id either as a filter or as part of the token scope.
But keystone instead of pulling the domain information from the token
scope (the or in that statement), keystone fails with an HTTP 401 if
you don't explicitly indicate the domain with the domain_id query
parameter, as shown with the following commands:
[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 401 Unauthorized
content-length: 114
vary: X-Auth-Token
server: Apache/2.4.6 (Red Hat) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
date: Wed, 11 Mar 2015 20:50:31 GMT
content-type: application/json
www-authenticate: Keystone
uri=https://ip9-114-226-167.pok.stglabs.ibm.com:5000;
{error: {message: The request you have made requires
authentication., code: 401, title: Unauthorized}}
[root@mysystem ~]# curl -k -X GET https://127.0.0.1:5000/v3/auth/tokens -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
-H X-Subject-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7 | python -mjson.tool
{
token: {
...
user: {
domain: {
id: default,
name: Default
},
id:
0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9,
name: root
}
}
}
[root@mysystem ~]# curl -k -i -X GET
https://127.0.0.1:5000/v3/groups?domain_id=default -H Accept:
application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 200 OK
...
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1431015
Title:
v3/users or groups calls not working without domain_id
Status in OpenStack Identity (Keystone):
New
Bug description:
The keystone.common.controller._get_domain_id_for_list_request comment says
the below:
Get the domain_id for a v3 list call.
If we running with multiple domain drivers, then the caller must
specify a domain_id either as a filter or as part of the token scope.
But keystone instead of pulling the domain information from the token
scope (the or in that statement), keystone fails with an HTTP 401 if
you don't explicitly indicate the domain with the domain_id query
parameter, as shown with the following commands:
[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 401 Unauthorized
content-length: 114
vary: X-Auth-Token
server: Apache/2.4.6 (Red Hat) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
date: Wed, 11 Mar 2015 20:50:31 GMT
content-type: application/json
www-authenticate: Keystone
uri=https://ip9-114-226-167.pok.stglabs.ibm.com:5000;
{error: {message: The request you have made requires
authentication., code: 401, title: Unauthorized}}
[root@mysystem ~]# curl -k -X GET https://127.0.0.1:5000/v3/auth/tokens -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
-H X-Subject-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7 | python -mjson.tool
{
token: {
...
user: {
domain: {
id: default,
name: Default
},
id:
0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9,
name: root
}
}
}
[root@mysystem ~]# curl -k -i -X GET
https://127.0.0.1:5000/v3/groups?domain_id=default -H Accept:
application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 200 OK
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1431015/+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 1431015] Re: v3/users or groups calls not working without domain_id
This was not an unscoped token. Requested as follows:
curl -k -i -X POST https://127.0.0.1:5000/v3/auth/tokens -H Accept:
application/json -H Content-Type: application/json -d '{auth:
{scope: {project: {name: ibm-default, domain: {name:
Default}}}, identity: {methods: [password], password: {user:
{domain: {name: Default}, name: root, password:
passw0rd}'
** Changed in: keystone
Status: Invalid = New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1431015
Title:
v3/users or groups calls not working without domain_id
Status in OpenStack Identity (Keystone):
New
Bug description:
The keystone.common.controller._get_domain_id_for_list_request comment says
the below:
Get the domain_id for a v3 list call.
If we running with multiple domain drivers, then the caller must
specify a domain_id either as a filter or as part of the token scope.
But keystone instead of pulling the domain information from the token
scope (the or in that statement), keystone fails with an HTTP 401 if
you don't explicitly indicate the domain with the domain_id query
parameter, as shown with the following commands:
[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 401 Unauthorized
content-length: 114
vary: X-Auth-Token
server: Apache/2.4.6 (Red Hat) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
date: Wed, 11 Mar 2015 20:50:31 GMT
content-type: application/json
www-authenticate: Keystone
uri=https://ip9-114-226-167.pok.stglabs.ibm.com:5000;
{error: {message: The request you have made requires
authentication., code: 401, title: Unauthorized}}
[root@mysystem ~]# curl -k -X GET https://127.0.0.1:5000/v3/auth/tokens -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
-H X-Subject-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7 | python -mjson.tool
{
token: {
...
project: {
domain: {
id: default,
name: Default
},
id: 0e2df62a46044405bb63be16ab9e2177,
name: ibm-default
},
...
user: {
domain: {
id: default,
name: Default
},
id:
0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9,
name: root
}
}
}
[root@mysystem ~]# curl -k -i -X GET
https://127.0.0.1:5000/v3/groups?domain_id=default -H Accept:
application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 200 OK
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1431015/+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 1427379] [NEW] AttributeError: 'Assignment' object has no attribute 'get_domain_by_name'
Public bug reported: 2015-03-02 13:16:45.493 19248 CRITICAL keystone [-] AttributeError: 'Assignment' object has no attribute 'get_domain_by_name' 2015-03-02 13:16:45.493 19248 TRACE keystone Traceback (most recent call last): 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/bin/keystone-manage, line 44, in module 2015-03-02 13:16:45.493 19248 TRACE keystone cli.main(argv=sys.argv, config_files=config_files) 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 311, in main 2015-03-02 13:16:45.493 19248 TRACE keystone CONF.command.cmd_class.main() 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 250, in main 2015-03-02 13:16:45.493 19248 TRACE keystone mapping['domain_id'] = get_domain_id(CONF.command.domain_name) 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 236, in get_domain_id 2015-03-02 13:16:45.493 19248 TRACE keystone return assignment_manager.driver.get_domain_by_name(name)['id'] 2015-03-02 13:16:45.493 19248 TRACE keystone AttributeError: 'Assignment' object has no attribute 'get_domain_by_name' ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: New ** Changed in: keystone Assignee: (unassigned) = Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1427379 Title: AttributeError: 'Assignment' object has no attribute 'get_domain_by_name' Status in OpenStack Identity (Keystone): New Bug description: 2015-03-02 13:16:45.493 19248 CRITICAL keystone [-] AttributeError: 'Assignment' object has no attribute 'get_domain_by_name' 2015-03-02 13:16:45.493 19248 TRACE keystone Traceback (most recent call last): 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/bin/keystone-manage, line 44, in module 2015-03-02 13:16:45.493 19248 TRACE keystone cli.main(argv=sys.argv, config_files=config_files) 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 311, in main 2015-03-02 13:16:45.493 19248 TRACE keystone CONF.command.cmd_class.main() 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 250, in main 2015-03-02 13:16:45.493 19248 TRACE keystone mapping['domain_id'] = get_domain_id(CONF.command.domain_name) 2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/lib/python2.7/site-packages/keystone/cli.py, line 236, in get_domain_id 2015-03-02 13:16:45.493 19248 TRACE keystone return assignment_manager.driver.get_domain_by_name(name)['id'] 2015-03-02 13:16:45.493 19248 TRACE keystone AttributeError: 'Assignment' object has no attribute 'get_domain_by_name' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1427379/+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 1386376] [NEW] endpoint url validation fails for IPv6 addresses
Public bug reported:
Can't create an endpoint with an IPv6 address in the URL. E.g.:
[root@ ~]# curl -k -i -X POST https://localhost:35357/v3/endpoints -H
Accept: application/json -H X-Auth-Token: 96d82b1a36a94b439fd91d2a875380be
-H Content-Type: application/json -d '{endpoint: {interface: admin,
name: metering, region: RegionOne, url:
https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2;, service_id:
57118ebd91094d7d8d609136d185f0dd}}'; echo
HTTP/1.1 400 Bad Request
Date: Mon, 27 Oct 2014 18:42:32 GMT
Server: Apache/2.2.15 (Red Hat)
Vary: X-Auth-Token
Content-Length: 182
Connection: close
Content-Type: application/json
{error: {message: KS-BAC2700 KS-6C5716A Invalid input for field
'url'. The value is
'https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2'., code: 400,
title: Bad Request}}
** Affects: keystone
Importance: Undecided
Assignee: Matthew Edmonds (edmondsw)
Status: New
** Changed in: keystone
Assignee: (unassigned) = Matthew Edmonds (edmondsw)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1386376
Title:
endpoint url validation fails for IPv6 addresses
Status in OpenStack Identity (Keystone):
New
Bug description:
Can't create an endpoint with an IPv6 address in the URL. E.g.:
[root@ ~]# curl -k -i -X POST https://localhost:35357/v3/endpoints -H
Accept: application/json -H X-Auth-Token: 96d82b1a36a94b439fd91d2a875380be
-H Content-Type: application/json -d '{endpoint: {interface: admin,
name: metering, region: RegionOne, url:
https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2;, service_id:
57118ebd91094d7d8d609136d185f0dd}}'; echo
HTTP/1.1 400 Bad Request
Date: Mon, 27 Oct 2014 18:42:32 GMT
Server: Apache/2.2.15 (Red Hat)
Vary: X-Auth-Token
Content-Length: 182
Connection: close
Content-Type: application/json
{error: {message: KS-BAC2700 KS-6C5716A Invalid input for field
'url'. The value is
'https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2'., code: 400,
title: Bad Request}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1386376/+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 1359376] [NEW] KeyError in GroupNotFound error path
Public bug reported: Hit the following exception: 2014-07-23 04:31:08.206 4449 ERROR keystone.common.wsgi [-] 'group_id' 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 207, in __call__ 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi result = method(context, **params) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/controller.py, line 196, in wrapper 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi return f(self, context, filters, **kwargs) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 876, in list_role_assignments 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi formatted_refs) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 811, in _ expand_indirect_assignments 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi members = _get_group_members(r) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 696, in _get_group_members 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi 'group': ref['group_id'], 'target': target, 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi KeyError: 'group_id' It appears that the dictionary format was changed and the error path code was not updated to expect the new format. ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: In Progress ** Changed in: keystone Status: New = In Progress ** Changed in: keystone Assignee: (unassigned) = Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1359376 Title: KeyError in GroupNotFound error path Status in OpenStack Identity (Keystone): In Progress Bug description: Hit the following exception: 2014-07-23 04:31:08.206 4449 ERROR keystone.common.wsgi [-] 'group_id' 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 207, in __call__ 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi result = method(context, **params) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/controller.py, line 196, in wrapper 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi return f(self, context, filters, **kwargs) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 876, in list_role_assignments 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi formatted_refs) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 811, in _ expand_indirect_assignments 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi members = _get_group_members(r) 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/controllers.py, line 696, in _get_group_members 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi 'group': ref['group_id'], 'target': target, 2014-07-23 04:31:08.206 4449 TRACE keystone.common.wsgi KeyError: 'group_id' It appears that the dictionary format was changed and the error path code was not updated to expect the new format. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1359376/+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 1358818] [NEW] extra_specs string check breaks backward compatibility
Public bug reported:
We've found that while with Icehouse we were able to specify extra_specs
values as ints or floats, in Juno the command fails unless we make these
values strings by quoting them. This breaks backward compatibility.
compare Icehouse:
curl -k -i -X POST
http://127.0.0.1:8774/v2/982607a6a1134514abac252fc25384ad/flavors/1/os-extra_specs
-H X-Auth-Token: * -H Accept: application/json -H Content-Type:
application/json -d
'{extra_specs:{powervm:proc_units:0.2,powervm:processor_compatibility:default,powervm:min_proc_units:0.1,powervm:max_proc_units:0.5,powervm:min_vcpu:1,powervm:max_vcpu:5,powervm:min_mem:1024,powervm:max_mem:4096,powervm:availability_priority:127,powervm:dedicated_proc:false,powervm:uncapped:true,powervm:shared_weight:128}}';
echo
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 385
X-Compute-Request-Id: req-9132922d-c703-4573-9822-9ca7a6bf7b0d
Date: Thu, 14 Aug 2014 18:25:02 GMT
{extra_specs: {powervm:processor_compatibility: default,
powervm:max_proc_units: 0.5, powervm:shared_weight: 128,
powervm:min_mem: 1024, powervm:max_mem: 4096, powervm:uncapped:
true, powervm:proc_units: 0.2, powervm:dedicated_proc: false,
powervm:max_vcpu: 5, powervm:availability_priority: 127,
powervm:min_proc_units: 0.1, powervm:min_vcpu: 1}}
to Juno:
curl -k -i -X POST
http://127.0.0.1:8774/v2/be2ffade1e0b4bed83619e00482317d1/flavors/1/os-extra_specs
-H X-Auth-Token: * -H Accept: application/json -H Content-Type:
application/json -d
'{extra_specs:{powervm:proc_units:0.2,powervm:processor_compatibility:default,powervm:min_proc_units:0.1,powervm:max_proc_units:0.5,powervm:min_vcpu:1,powervm:max_vcpu:5,powervm:min_mem:1024,powervm:max_mem:4096,powervm:availability_priority:127,powervm:dedicated_proc:false,powervm:uncapped:true,powervm:shared_weight:128}}';
echo
HTTP/1.1 400 Bad Request
Content-Length: 88
Content-Type: application/json; charset=UTF-8
Date: Thu, 14 Aug 2014 18:25:46 GMT
{badRequest: {message: extra_specs value is not a string or
unicode, code: 400}}
if I modify the data sent so that everything is a string, it will work for Juno:
curl -k -i -X POST
http://127.0.0.1:8774/v2/be2ffade1e0b4bed83619e00482317d1/flavors/1/os-extra_specs
-H X-Auth-Token: * -H Accept: application/json -H Content-Type:
application/json -d
'{extra_specs:{powervm:proc_units:0.2,powervm:processor_compatibility:default,powervm:min_proc_units:0.1,powervm:max_proc_units:0.5,powervm:min_vcpu:1,powervm:max_vcpu:5,powervm:min_mem:1024,powervm:max_mem:4096,powervm:availability_priority:127,powervm:dedicated_proc:false,powervm:uncapped:true,powervm:shared_weight:128}}';
echo
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 397
Date: Thu, 14 Aug 2014 18:26:27 GMT
{extra_specs: {powervm:processor_compatibility: default,
powervm:max_proc_units: 0.5, powervm:shared_weight: 128,
powervm:min_mem: 1024, powervm:max_mem: 4096,
powervm:uncapped: true, powervm:proc_units: 0.2,
powervm:dedicated_proc: false, powervm:max_vcpu: 5,
powervm:availability_priority: 127, powervm:min_proc_units: 0.1,
powervm:min_vcpu: 1}}
The API change guidelines (https://wiki.openstack.org/wiki/APIChangeGuidelines)
describe as generally not acceptable: A change such that a request which was
successful before now results in an error response (unless the success reported
previously was hiding an existing error condition). That is exactly what this
is.
** 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/1358818
Title:
extra_specs string check breaks backward compatibility
Status in OpenStack Compute (Nova):
New
Bug description:
We've found that while with Icehouse we were able to specify
extra_specs values as ints or floats, in Juno the command fails unless
we make these values strings by quoting them. This breaks backward
compatibility.
compare Icehouse:
curl -k -i -X POST
http://127.0.0.1:8774/v2/982607a6a1134514abac252fc25384ad/flavors/1/os-extra_specs
-H X-Auth-Token: * -H Accept: application/json -H Content-Type:
application/json -d
'{extra_specs:{powervm:proc_units:0.2,powervm:processor_compatibility:default,powervm:min_proc_units:0.1,powervm:max_proc_units:0.5,powervm:min_vcpu:1,powervm:max_vcpu:5,powervm:min_mem:1024,powervm:max_mem:4096,powervm:availability_priority:127,powervm:dedicated_proc:false,powervm:uncapped:true,powervm:shared_weight:128}}';
echo
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 385
X-Compute-Request-Id: req-9132922d-c703-4573-9822-9ca7a6bf7b0d
Date: Thu, 14 Aug 2014 18:25:02 GMT
{extra_specs: {powervm:processor_compatibility: default,
powervm:max_proc_units: 0.5, powervm:shared_weight: 128,
powervm:min_mem: 1024, powervm:max_mem: 4096, powervm:uncapped:
true, powervm:proc_units: 0.2, powervm:dedicated_proc:
[Yahoo-eng-team] [Bug 1298131] [NEW] improper usage of HTTP 413 status code
Public bug reported:
HTTP 413 is supposed to mean (per RFC2616) that the request entity was
too large. E.g., if you send an enormous body with the request. That is
not at all how it is being used in the server resize request example
below. The nova/api/openstack/compute/servers.py is coded to return 413
for QuotaError and PortLimitExceeded on create as well as for QuotaError
on resize, and there may be other places 413 is being returned
inappropriately.
POST
https://9.5.126.113/powervc/openstack/compute/v2/6ce8fae0510349dcbf9b3965f7a20061/servers/8ebaabfc-9018-4ac1-afc6-630aee8a8ae3/action
Request body: { resize: {
flavor: {
vcpus: 1,
ram: 99,
disk: 20
}}}
Response: HTTP 413 (Request Entity Too Large)
Response body:
{
overLimit: {
message: NV-02B1F9F Quota exceeded for ram: Requested 1410063359, but already
used 6144 of 800 ram
code: 413
retryAfter: 0
}
-
}
** 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/1298131
Title:
improper usage of HTTP 413 status code
Status in OpenStack Compute (Nova):
New
Bug description:
HTTP 413 is supposed to mean (per RFC2616) that the request entity was
too large. E.g., if you send an enormous body with the request. That
is not at all how it is being used in the server resize request
example below. The nova/api/openstack/compute/servers.py is coded to
return 413 for QuotaError and PortLimitExceeded on create as well as
for QuotaError on resize, and there may be other places 413 is being
returned inappropriately.
POST
https://9.5.126.113/powervc/openstack/compute/v2/6ce8fae0510349dcbf9b3965f7a20061/servers/8ebaabfc-9018-4ac1-afc6-630aee8a8ae3/action
Request body: { resize: {
flavor: {
vcpus: 1,
ram: 99,
disk: 20
}}}
Response: HTTP 413 (Request Entity Too Large)
Response body:
{
overLimit: {
message: NV-02B1F9F Quota exceeded for ram: Requested 1410063359, but
already used 6144 of 800 ram
code: 413
retryAfter: 0
}
-
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298131/+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 1288814] Re: limits API raises TypeError with NoopQuotaDriver
*** This bug is a duplicate of bug 1244842 ***
https://bugs.launchpad.net/bugs/1244842
I was using havana, apparently pre-backport. Marked this as a dup. Thank
you.
** This bug has been marked a duplicate of bug 1244842
NoopQuotaDriver returns usages incorrect format
--
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/1288814
Title:
limits API raises TypeError with NoopQuotaDriver
Status in OpenStack Compute (Nova):
Incomplete
Bug description:
when quota_driver=nova.quota.NoopQuotaDriver in nova.conf, a GET
v2/{tenant_id}/limits request fails with HTTP 400 and api.log shows
the following stacktrace:
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi Traceback (most
recent call last):
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1012, in
_process_stack
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi action_result =
self.dispatch(meth, request, action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1093, in
dispatch
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi return
method(req=request, **action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in index
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in genexpr
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi TypeError: 'int'
object is unsubscriptable
This appears to be because v = -1 for all resources with the
NoopQuotaDriver
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1288814/+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 1288814] [NEW] limits API raises TypeError with NoopQuotaDriver
Public bug reported:
when quota_driver=nova.quota.NoopQuotaDriver in nova.conf, a GET
v2/{tenant_id}/limits request fails with HTTP 400 and api.log shows the
following stacktrace:
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi Traceback (most
recent call last):
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1012, in
_process_stack
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi action_result =
self.dispatch(meth, request, action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1093, in
dispatch
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi return
method(req=request, **action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in index
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in genexpr
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi TypeError: 'int'
object is unsubscriptable
This appears to be because v = -1 for all resources with the
NoopQuotaDriver
** 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/1288814
Title:
limits API raises TypeError with NoopQuotaDriver
Status in OpenStack Compute (Nova):
New
Bug description:
when quota_driver=nova.quota.NoopQuotaDriver in nova.conf, a GET
v2/{tenant_id}/limits request fails with HTTP 400 and api.log shows
the following stacktrace:
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi Traceback (most
recent call last):
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1012, in
_process_stack
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi action_result =
self.dispatch(meth, request, action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py, line 1093, in
dispatch
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi return
method(req=request, **action_args)
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in index
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi File
/usr/lib/python2.6/site-packages/nova/api/openstack/compute/limits.py, line
96, in genexpr
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi abs_limits =
dict((k, v['limit']) for k, v in quotas.items())
2014-03-03 04:16:31.468 3182 TRACE nova.api.openstack.wsgi TypeError: 'int'
object is unsubscriptable
This appears to be because v = -1 for all resources with the
NoopQuotaDriver
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1288814/+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
