Bug 1487619 - RFE: All created metrics are under the ceilometer user and services project [NEEDINFO]
Summary: RFE: All created metrics are under the ceilometer user and services project
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: gnocchi
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
Target Milestone: Upstream M2
: 13.0 (Queens)
Assignee: Pradeep Kilambi
QA Contact: Sasha Smolyak
: 1504056 (view as bug list)
Depends On:
Blocks: 1530406
TreeView+ depends on / blocked
Reported: 2017-09-01 12:20 UTC by David Hill
Modified: 2021-09-09 12:34 UTC (History)
12 users (show)

Fixed In Version: gnocchi-4.2.1-0.20180216183203.55d3de1.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1530406 (view as bug list)
Last Closed: 2018-06-27 13:36:15 UTC
Target Upstream Version:
knylande: needinfo? (pkilambi)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github gnocchixyz gnocchi issues 314 0 'None' 'closed' 'Metric listing do not include accessible metrics' 2019-11-29 03:31:38 UTC
Red Hat Product Errata RHEA-2018:2086 0 None None None 2018-06-27 13:37:07 UTC

Description David Hill 2017-09-01 12:20:21 UTC
Description of problem:
All created metrics are under the ceilometer user and services project and listing them with a user expecting to get a list of own metrics will always return an empty array [] unless ran under an admin account.   This is due to the way metrics are created and how they are fetched in /usr/lib/python2.7/site-packages/gnocchi/rest/__init__.py since the user metrics are filtered with created_by_user_id and created_by_project_id which will never be the user own project/user id.   I also think that due to this, a given user would not receive all the metrics created within a project due to the use of the following condition:

        if user_id is not None:
            attr_filter['created_by_user_id'] = user_id

in the following code block:

def get_all(**kwargs):
            enforce("list all metric", {})
        except webob.exc.HTTPForbidden:
            enforce("list metric", {})
            user_id, project_id = get_user_and_project()
            provided_user_id = kwargs.get('user_id')
            provided_project_id = kwargs.get('project_id')
            if ((provided_user_id and user_id != provided_user_id)
               or (provided_project_id and project_id != provided_project_id)):
                    403, "Insufficient privileges to filter by user/project")
            user_id = kwargs.get('user_id')
            project_id = kwargs.get('project_id')
        attr_filter = {}
        if user_id is not None:
            attr_filter['created_by_user_id'] = user_id
        if project_id is not None:
            attr_filter['created_by_project_id'] = project_id
            kwargs, METRIC_DEFAULT_PAGINATION))
            return pecan.request.indexer.list_metrics(**attr_filter)
        except indexer.IndexerException as e:
            abort(400, e)
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 David Hill 2017-09-01 12:55:40 UTC
One of the current work around would be to use "gnocchi resource list" then, "gnocchi resource show UUID" of one of the instance.   In the following output, there's a "metrics" blob containing all the related metrics to that instance, you can then use "gnocchi metric show UUID" or "gnocchi measures show UUID" in order to get the parameters of that metric or the measures values.

Comment 2 Julien Danjou 2017-09-01 12:57:50 UTC
This should be considered as a RFE. It might not be so easy to improve as oslo.policy can be quite limited for such ACL management.

Comment 3 David Hill 2017-09-01 14:24:46 UTC
From a customer point of view , this would be a bug but I don't mind changing it for RFE if it's the only way to get it improved from our side of the table.

Comment 5 Julien Danjou 2017-10-19 12:12:17 UTC
*** Bug 1504056 has been marked as a duplicate of this bug. ***

Comment 12 Sasha Smolyak 2017-12-19 13:43:32 UTC
The patch has been merged upstream and it will be part of OSP13

Comment 33 errata-xmlrpc 2018-06-27 13:36:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.