Handle multiple datasources independently from the strategy

Registered by Vincent Françoise

By the end of the Ocata cycle, Ceilometer will be deprecated. Therefore, we need to propose a different viable data source in Watcher as a replacement. With this in mind https://blueprints.launchpad.net/watcher/+spec/monasca-support has been proposed and will be implemented by the end of the Ocata cycle. However, the OpenStack community currently offers 2 alternatives for querying metrics which are Monasca and Gnocchi. Moerever, other backends may be considered such as Prometheus or Zabbix (see Vitrage).

As we do not want/should to favor any of both in order to maximize the potential of Watcher, the next move should be to propose a Gnocchi helper that would be interchangeable with the Monasca one. That being said, 2 implementation approaches can be made:

- Create an abstraction layer that creates a DSL that would be converted down to its backend-specific counterpart. This means that the translation layer would have to be maintained thoroughly maintained within Watcher. THis DSL should also be as permissive as possible in order to allow most query structures. This work is very complex as it may not easily fit to many backends.
- Rely on a datasource manager that would be responsible for choosing/channeling to the best suited backend a given metric request. To do so, it would first check the capabilities declared and implemented by each backend client via an interface mechanism. These capabilities would be business related queries that would be translated to a preformated native query given some required inputs. The second and final step would then consist of applying a (configurable) weight to each available+capable backend still remaining and select the one that sits on top. This approach means that we would have to implemented & maintain the datasource manager along with the necessary set of capability interfaces. Futhermore, we would need to provide the implementation of these interfaces for Ceilometer, Gnocchi and Monasca.

As of now, the second solution seems to be the most feature-complete way to achieve a clean abstraction to seemlessly deal with many different datasources at the same time from a strategy perspective.

======= Implementation hints for Option 2 ===========

class MyStrategy(object):

    def do_execute(self):
        manager = self.get_datasource_manager()

        backend = manager.get_datasource('cpu_usage')
        backend.get_resource_cpu_usage(node)
        # [...]

# In setup.cfg
watcher.datasource.capabilities =
    cpu_usage = watcher.somewhere.datasource.interfaces:CpuUsage

# in watcher/somewhere/datasource/interfaces.py
@abstractclass
class CpuUsage(object)

    def get_resource_cpu_usage(self, resource):
        raise NotImplementedError()

# in watcher/somewhere/datasource/monasca.py
class Monasca(DataSource, CpuUsage):

    def get_resource_cpu_usage(self, resource):
        # TODO
        pass

# in watcher/somewhere/datasource/ceilometer.py
class Ceilometer(DataSource, CpuUsage):

    def get_resource_cpu_usage(self, resource):
        # TODO
        pass

# in watcher/somewhere/datasource/gnocchi.py
class Gnocchi(DataSource, CpuUsage):

    def get_resource_cpu_usage(self, resource):
        # TODO
        pass

From last PTG discussion (https://etherpad.openstack.org/p/pike-watcher-ptg)
we need an abstraction layer with a minimal subset of metrics needed by existing strategies (it will deal with gnocchi & monasca)
if we have multiple metrics collection backend deployed, the strategy will need to give the back-end it wants to use / alternatively we could define a backend priority in configuration
we will need a map between metrics names used by strategies and correspond names in backends

Blueprint information

Status:
Complete
Approver:
Antoine Cabot
Priority:
Low
Drafter:
Vincent Françoise
Direction:
Approved
Assignee:
aditi sharma
Definition:
Approved
Series goal:
Accepted for queens
Implementation:
Implemented
Milestone target:
None
Started by
Alexander Chadin
Completed by
Alexander Chadin

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/watcher-multi-datasource,n,z

Addressed by: https://review.openstack.org/467102
    Spec for multi-datasource support

Addressed by: https://review.openstack.org/508384
    Add Datasource Abstraction and Multi Datasource

Addressed by: https://review.openstack.org/518852
    Add Datasource Abstraction

Gerrit topic: https://review.openstack.org/#q,topic:bp/check-strategy-requirements,n,z

Addressed by: https://review.openstack.org/527639
    Adapt workload_stabilization strategy to new datasource backend

Addressed by: https://review.openstack.org/529338
    Adapt basic_consolidation strategy to multiple datasource backend

Addressed by: https://review.openstack.org/529815
    Adapt noisy_neighbor strategy to multiple datasource backend

Addressed by: https://review.openstack.org/532796
    Adapt workload_balance strategy to multiple datasource backend

Addressed by: https://review.openstack.org/539182
    Fix issues with aggregate and granularity attributes

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.