Add a new pdf-docs environment to enable PDF build. sphinxcontrib-svg2pdfconverter is used to handle SVG properly. Change-Id: I1563579486da8912ba8a220bb08a5331e7df910b
12 KiB
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>
andAction 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 Scope
An Audit Scope is a set of audited resources. Audit Scope should be defined in each Audit Template (which contains the Audit settings).
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
Controller Node
Please, read the official OpenStack definition of a Controller Node.
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 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 AgreementSLO <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