This page presents the current technical Architecture of the Watcher system.
The AMQP message bus handles internal asynchronous communications between the different Watcher components.
This component stores the metrics related to the cluster.
It can potentially rely on any appropriate storage system (InfluxDB, OpenTSDB, MongoDB,…) but will probably be more performant when using Time Series Databases which are optimized for handling time series data, which are arrays of numbers indexed by time (a datetime or a datetime range).
This component implements the REST API provided by the Watcher system to the external world.
It enables the Administrator of a Cluster to control and monitor the Watcher system via any interaction mechanism connected to this API:
You can also read the detailed description of Watcher API.
This component is in charge of executing the Action Plan built by the Watcher Decision Engine. Taskflow is the default workflow engine for Watcher.
It connects to the message bus and launches the Action Plan whenever a triggering message is received on a dedicated AMQP queue.
The triggering message contains the Action Plan UUID.
It then gets the detailed information about the Action Plan from the Watcher Database which contains the list of Actions to launch.
It then loops on each Action, gets the associated class and calls the execute() method of this class. Most of the time, this method will first request a token to the Keystone API and if it is allowed, sends a request to the REST API of the OpenStack service which handles this kind of atomic Action.
Note that as soon as Watcher Applier starts handling a given Action from the list, a notification message is sent on the message bus indicating that the state of the action has changed to ONGOING.
If the Action is successful, the Watcher Applier sends a notification message on the bus informing the other components of this.
If the Action fails, the Watcher Applier tries to rollback to the previous state of the Managed resource (i.e. before the command was sent to the underlying OpenStack service).
In Stein, added a new config option ‘action_execution_rule’ which is a dict type. Its key field is strategy name and the value is ‘ALWAYS’ or ‘ANY’. ‘ALWAYS’ means the callback function returns True as usual. ‘ANY’ means the return depends on the result of previous action execution. The callback returns True if previous action gets failed, and the engine continues to run the next action. If previous action executes success, the callback returns False then the next action will be ignored. For strategies that aren’t in ‘action_execution_rule’, the callback always returns True. Please add the next section in the watcher.conf file if your strategy needs this feature.
[watcher_workflow_engines.taskflow]
action_execution_rule = {'your strategy name': 'ANY'}
The watcher command-line interface (CLI) can be used to interact with the Watcher system in order to control it or to know its current status.
Please, read the detailed documentation about Watcher CLI.
The Watcher Dashboard can be used to interact with the Watcher system through Horizon in order to control it or to know its current status.
Please, read the detailed documentation about Watcher Dashboard.
This database stores all the Watcher domain objects which can be requested by the Watcher API or the Watcher CLI:
The Watcher domain being here “optimization of some resources provided by an OpenStack system”.
This component is responsible for computing a set of potential optimization Actions in order to fulfill the Goal of an Audit.
It first reads the parameters of the Audit to know the Goal to achieve.
Unless specified, it then selects the most appropriate strategy from the list of available strategies achieving this goal.
The Strategy is then dynamically loaded (via stevedore). The Watcher Decision Engine executes the strategy.
In order to compute the potential Solution for the Audit, the Strategy relies on different sets of data:
Here below is a sequence diagram showing how the Decision Engine builds and maintains the cluster data models that are used by the strategies.
The execution of a strategy then yields a solution composed of a set of Actions as well as a set of efficacy indicators.
These Actions are scheduled in time by the Watcher Planner (i.e., it generates an Action Plan).
The following diagram shows the data model of Watcher, especially the functional dependency of objects from the actors (Admin, Customer) point of view (Goals, Audits, Action Plans, …):
Here below is a diagram representing the main objects in Watcher from a database perspective:
The following paragraph shows the messages exchanged between the different components of Watcher for the most often used scenarios.
The Administrator first creates an Audit template providing at least the following parameters:
The Watcher API makes sure that both the specified goal (mandatory) and its associated strategy (optional) are registered inside the Watcher Database before storing a new audit template in the Watcher Database.
The Administrator can then launch a new Audit by providing at least the unique UUID of the previously created Audit template:
The Administrator also can specify type of Audit and interval (in case of CONTINUOUS type). There is two types of Audit: ONESHOT and CONTINUOUS. Oneshot Audit is launched once and if it succeeded executed new action plan list will be provided. Continuous Audit creates action plans with specified interval (in seconds); if action plan has been created, all previous action plans get CANCELLED state.
A message is sent on the AMQP bus which triggers the Audit in the Watcher Decision Engine:
The Watcher Decision Engine reads the Audit parameters from the Watcher Database. It instantiates the appropriate strategy (using entry points) given both the goal and the strategy associated to the parent audit template of the audit. If no strategy is associated to the audit template, the strategy is dynamically selected by the Decision Engine.
The Watcher Decision Engine also builds the Cluster Data Model. This data model is needed by the Strategy to know the current state and topology of the audited OpenStack cluster.
The Watcher Decision Engine calls the execute() method of the instantiated Strategy and provides the data model as an input parameter. This method computes a Solution to achieve the goal and returns it to the Decision Engine. At this point, actions are not scheduled yet.
The Watcher Decision Engine dynamically loads the Watcher Planner implementation which is configured in Watcher (via entry points) and calls the schedule() method of this class with the solution as an input parameter. This method finds an appropriate scheduling of Actions taking into account some scheduling rules (such as priorities between actions). It generates a new Action Plan with status RECOMMENDED and saves it into the Watcher Database. The saved action plan is now a scheduled flow of actions to which a global efficacy is associated alongside a number of Efficacy Indicators as specified by the related goal.
If every step executed successfully, the Watcher Decision Engine updates the current status of the Audit to SUCCEEDED in the Watcher Database and sends a notification on the bus to inform other components that the Audit was successful.
This internal workflow the Decision Engine follows to conduct an audit can be seen in the sequence diagram here below:
The Administrator can then launch the recommended Action Plan:
A message is sent on the AMQP bus which triggers the Action Plan in the Watcher Applier:
The Watcher Applier will get the description of the flow of Actions from the Watcher Database and for each Action it will instantiate a corresponding Action handler python class.
The Watcher Applier will then call the following methods of the Action handler:
If every action of the action flow has been executed successfully, a notification is sent on the bus to indicate that the whole Action Plan has SUCCEEDED.
An Audit has a life-cycle and its current state may be one of the following:
The following diagram shows the different possible states of an Audit and what event makes the state change to a new value:
An Action Plan has a life-cycle and its current state may be one of the following:
The following diagram shows the different possible states of an Action Plan and what event makes the state change to a new value:
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.