Cloudkitty monasca fetcher implementation¶
Monasca is already supported in cloudkitty through its collector. However, cloudkitty lacks a dedicated fetcher for monasca, relying instead on other fetchers.
No scope discovery is available when using the monasca collector. This forces users to use the keystone fetcher and assign the ‘rating’ role to every project where cloudkitty is needed. Another less than ideal solution is to use the ‘source’ fetcher, but that requires to specify every scope in the configuration file.
Implementing a new fetcher using monasca to discover scopes:
The fetcher will connect to monasca and retrieve a list of scopes (dimensions values in monasca) given a specified dimension name. This is achieved through monasca’s python client and its
The monasca endpoint will be retrieved from keystone in similar fashion to the monasca collector, as it is needed for the monasca client initialization. This is a good opportunity to mutualize the monasca’s client bootstraping code in a common file.
Configuration options include:
dimension_name: the monasca dimension from which the scope_ids should be retrieved, defaults to
monasca_tenant_id: The monasca tenant id, has no default value.
monasca_service_name: Name of the monasca service, defaults to
interface: Endpoint type, defaults to
Data model impact¶
REST API impact¶
The fetcher will use the same authentication mechanism as the current monasca collector (keystone for authentication and python-monascaclient for monasca interactions), and won’t introduce any new dependency. Thus, the new fetcher shouldn’t have any security impact.
Other end user impact¶
Other deployer impact¶
- Primary assignee:
- Other contributors:
Implement a cloudkitty monasca scope fetcher using python-monascaclient.
No new dependency is needed.
Regular unit tests will be included.
Documentation of the new fetcher will be added, mostly covering configuration of the fetcher.