watcher/doc/source/glossary.rst

Glossary

This page explains the different terms used in the Watcher system.

They are sorted in alphabetical order.

Action

watcher.api.controllers.v1.action

Action Plan

watcher.api.controllers.v1.action_plan

Administrator

The Administrator <administrator_definition> is any user who has admin access on the OpenStack cluster. This user is allowed to create new projects for tenants, create new users and assign roles to each user.

The Administrator <administrator_definition> usually has remote access to any host of the cluster in order to change the configuration and restart any OpenStack service, including Watcher.

In the context of Watcher, the Administrator <administrator_definition> is a role for users which allows them to run any Watcher commands, such as:

• Create/Delete an Audit Template <audit_template_definition>
• Launch an Audit <audit_definition>
• Get the Action Plan <action_plan_definition>
• Launch a recommended Action Plan <action_plan_definition> manually
• Archive previous Audits <audit_definition> and Action Plans <action_plan_definition>

The Administrator <administrator_definition> is also allowed to modify any Watcher configuration files and to restart Watcher services.

Audit

watcher.api.controllers.v1.audit

Audit Template

watcher.api.controllers.v1.audit_template

Availability Zone

Please, read the official OpenStack definition of an Availability Zone.

Cluster

A Cluster <cluster_definition> is a set of physical machines which provide compute, storage and networking resources and are managed by the same OpenStack Controller node. A Cluster <cluster_definition> represents a set of resources that a cloud provider is able to offer to his/her customers <customer_definition>.

A data center may contain several clusters.

The Cluster <cluster_definition> may be divided in one or several Availability Zone(s) <availability_zone_definition>.

Cluster Data Model (CDM)

watcher.decision_engine.model.collector.base

Cluster History

watcher.decision_engine.cluster.history.base

Controller Node

A controller node is a machine that typically runs the following core OpenStack services:

• Keystone: for identity and service management
• Cinder scheduler: for volumes management
• Glance controller: for image management
• Neutron controller: for network management
• Nova controller: for global compute resources management with services such as nova-scheduler, nova-conductor and nova-network.

In many configurations, Watcher will reside on a controller node even if it can potentially be hosted on a dedicated machine.

Compute node

Please, read the official OpenStack definition of a Compute Node.

Customer

A Customer <customer_definition> is the person or company which subscribes to the cloud provider offering. A customer may have several Project(s) <project_definition> hosted on the same Cluster <cluster_definition> or dispatched on different clusters.

In the private cloud context, the Customers <customer_definition> are different groups within the same organization (different departments, project teams, branch offices and so on). Cloud infrastructure includes the ability to precisely track each customer's service usage so that it can be charged back to them, or at least reported to them.

Goal

watcher.api.controllers.v1.goal

Host Aggregate

Please, read the official OpenStack definition of a Host Aggregate.

Instance

A running virtual machine, or a virtual machine in a known state such as suspended, that can be used like a hardware server.

Managed resource

A Managed resource <managed_resource_definition> is one instance of Managed resource type <managed_resource_type_definition> in a topology with particular properties and dependencies on other Managed resources <managed_resource_definition> (relationships).

For example, a Managed resource <managed_resource_definition> can be one virtual machine (i.e., an instance <instance_definition>) hosted on a compute node <compute_node_definition> and connected to another virtual machine through a network link (represented also as a Managed resource <managed_resource_definition> in the Cluster Data Model <cluster_data_model_definition>).

Managed resource type

A Managed resource type <managed_resource_definition> is a type of hardware or software element of the Cluster <cluster_definition> that the Watcher system can act on.

Here are some examples of Managed resource types <managed_resource_definition>:

• Nova Host Aggregates
• Nova Servers
• Cinder Volumes
• Neutron Routers
• Neutron Networks
• Neutron load-balancers
• Sahara Hadoop Cluster
• ...

It can be any of the the official list of available resource types defined in OpenStack for HEAT.

Efficacy Indicator

watcher.api.controllers.v1.efficacy_indicator

Efficacy Specification

watcher.decision_engine.goal.efficacy.base

Optimization Efficacy

The Optimization Efficacy <efficacy_definition> is the objective measure of how much of the Goal <goal_definition> has been achieved in respect with constraints and SLAs <sla_definition> defined by the Customer <customer_definition>.

The way efficacy is evaluated will depend on the Goal <goal_definition> to achieve.

Of course, the efficacy will be relevant only as long as the Action Plan <action_plan_definition> is relevant (i.e., the current state of the Cluster <cluster_definition> has not changed in a way that a new Audit <audit_definition> would need to be launched).

For example, if the Goal <goal_definition> is to lower the energy consumption, the Efficacy <efficacy_definition> will be computed using several efficacy indicators <efficacy_indicator_definition> (KPIs):

• the percentage of energy gain (which must be the highest possible)
• the number of SLA violations <sla_violation_definition> (which must be the lowest possible)
• the number of virtual machine migrations (which must be the lowest possible)

All those indicators are computed within a given timeframe, which is the time taken to execute the whole Action Plan <action_plan_definition>.

The efficacy also enables the Administrator <administrator_definition> to objectively compare different Strategies <strategy_definition> for the same goal and same workload of the Cluster <cluster_definition>.

Project

Projects <project_definition> represent the base unit of “ownership” in OpenStack, in that all resources <managed_resource_definition> in OpenStack should be owned by a specific project <project_definition>. In OpenStack Identity, a project <project_definition> must be owned by a specific domain.

Please, read the official OpenStack definition of a Project.

Scoring Engine

watcher.api.controllers.v1.scoring_engine

SLA

SLA <sla_definition> means Service Level Agreement.

The resources are negotiated between the Customer <customer_definition> and the Cloud Provider in a contract.

Most of the time, this contract is composed of two documents:

• SLA <sla_definition> : Service Level Agreement
• SLO <slo_definition> : Service Level Objectives

Note that the SLA <sla_definition> is more general than the SLO <slo_definition> in the sense that the former specifies what service is to be provided, how it is supported, times, locations, costs, performance, and responsibilities of the parties involved while the SLO <slo_definition> focuses on more measurable characteristics such as availability, throughput, frequency, response time or quality.

You can also read the Wikipedia page for SLA which provides a good definition.

SLA violation

A SLA violation <sla_violation_definition> happens when a SLA <sla_definition> defined with a given Customer <customer_definition> could not be respected by the cloud provider within the timeframe defined by the official contract document.

SLO

A Service Level Objective (SLO) is a key element of a SLA <sla_definition> between a service provider and a Customer <customer_definition>. SLOs are agreed as a means of measuring the performance of the Service Provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding.

You can also read the Wikipedia page for SLO which provides a good definition.

Solution

watcher.decision_engine.solution.base

Strategy

watcher.api.controllers.v1.strategy

Watcher Applier

watcher.applier.base

Watcher Database

This database stores all the Watcher domain objects which can be requested by the Watcher API or the Watcher CLI:

• Audit templates
• Audits
• Action plans
• Actions
• Goals

The Watcher domain being here "optimization of some resources provided by an OpenStack system".

See architecture for more details on this component.

Watcher Decision Engine

watcher.decision_engine.manager

Watcher Planner

watcher.decision_engine.planner.base