Bug 1487619

Summary: RFE: All created metrics are under the ceilometer user and services project
Product: Red Hat OpenStack Reporter: David Hill <dhill>
Component: gnocchiAssignee: Pradeep Kilambi <pkilambi>
Status: CLOSED ERRATA QA Contact: Sasha Smolyak <ssmolyak>
Severity: high Docs Contact:
Priority: high    
Version: 10.0 (Newton)CC: apevec, dhill, fbaudin, jdanjou, jjoyce, jschluet, knylande, lhh, marjones, pkilambi, sclewis, ssmolyak
Target Milestone: Upstream M2Keywords: FutureFeature, Triaged
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gnocchi-4.2.1-0.20180216183203.55d3de1.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1530406 (view as bug list) Environment:
Last Closed: 2018-06-27 13:36:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1530406    

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):
        try:
            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)):
                abort(
                    403, "Insufficient privileges to filter by user/project")
        else:
            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
        attr_filter.update(get_pagination_options(
            kwargs, METRIC_DEFAULT_PAGINATION))
        try:
            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:
1.
2.
3.

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.

https://access.redhat.com/errata/RHEA-2018:2086

Comment 34 Red Hat Bugzilla 2023-09-15 01:26:20 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days