.. Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. You can view the license at: https://creativecommons.org/licenses/by/3.0/ ======== Glossary ======== .. glossary:: :sorted: This page explains the different terms used in the Watcher system. They are sorted in alphabetical order. .. _action_definition: Action ====== .. watcher-term:: watcher.api.controllers.v1.action .. _action_plan_definition: Action Plan =========== .. watcher-term:: watcher.api.controllers.v1.action_plan .. _administrator_definition: Administrator ============= The :ref:`Administrator ` 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 :ref:`Administrator ` 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 :ref:`Administrator ` is a role for users which allows them to run any Watcher commands, such as: - Create/Delete an :ref:`Audit Template ` - Launch an :ref:`Audit ` - Get the :ref:`Action Plan ` - Launch a recommended :ref:`Action Plan ` manually - Archive previous :ref:`Audits ` and :ref:`Action Plans ` The :ref:`Administrator ` is also allowed to modify any Watcher configuration files and to restart Watcher services. .. _audit_definition: Audit ===== .. watcher-term:: watcher.api.controllers.v1.audit .. _audit_template_definition: Audit Template ============== .. watcher-term:: watcher.api.controllers.v1.audit_template .. _availability_zone_definition: Availability Zone ================= Please, read `the official OpenStack definition of an Availability Zone `_. .. _cluster_definition: Cluster ======= A :ref:`Cluster ` is a set of physical machines which provide compute, storage and networking resources and are managed by the same OpenStack Controller node. A :ref:`Cluster ` represents a set of resources that a cloud provider is able to offer to his/her :ref:`customers `. A data center may contain several clusters. The :ref:`Cluster ` may be divided in one or several :ref:`Availability Zone(s) `. .. _cluster_data_model_definition: Cluster Data Model ================== .. watcher-term:: watcher.decision_engine.model.collector.base .. _cluster_history_definition: Cluster History =============== .. watcher-term:: watcher.decision_engine.cluster.history.base .. _controller_node_definition: 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_definition: Compute node ============ Please, read `the official OpenStack definition of a Compute Node `_. .. _customer_definition: Customer ======== A :ref:`Customer ` is the person or company which subscribes to the cloud provider offering. A customer may have several :ref:`Project(s) ` hosted on the same :ref:`Cluster ` or dispatched on different clusters. In the private cloud context, the :ref:`Customers ` 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_definition: Goal ==== .. watcher-term:: watcher.api.controllers.v1.goal .. _host_aggregates_definition: Host Aggregate ============== Please, read `the official OpenStack definition of a Host Aggregate `_. .. _instance_definition: 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_definition: Managed resource ================ A :ref:`Managed resource ` is one instance of :ref:`Managed resource type ` in a topology with particular properties and dependencies on other :ref:`Managed resources ` (relationships). For example, a :ref:`Managed resource ` can be one virtual machine (i.e., an :ref:`instance `) hosted on a :ref:`compute node ` and connected to another virtual machine through a network link (represented also as a :ref:`Managed resource ` in the :ref:`Cluster Data Model `). .. _managed_resource_type_definition: Managed resource type ===================== A :ref:`Managed resource type ` is a type of hardware or software element of the :ref:`Cluster ` that the Watcher system can act on. Here are some examples of :ref:`Managed resource types `: - `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_definition: Efficacy Indicator ================== .. watcher-term:: watcher.api.controllers.v1.efficacy_indicator .. _efficacy_specification_definition: Efficacy Specification ====================== .. watcher-term:: watcher.decision_engine.goal.efficacy.base .. _efficacy_definition: Optimization Efficacy ===================== The :ref:`Optimization Efficacy ` is the objective measure of how much of the :ref:`Goal ` has been achieved in respect with constraints and :ref:`SLAs ` defined by the :ref:`Customer `. The way efficacy is evaluated will depend on the :ref:`Goal ` to achieve. Of course, the efficacy will be relevant only as long as the :ref:`Action Plan ` is relevant (i.e., the current state of the :ref:`Cluster ` has not changed in a way that a new :ref:`Audit ` would need to be launched). For example, if the :ref:`Goal ` is to lower the energy consumption, the :ref:`Efficacy ` will be computed using several :ref:`efficacy indicators ` (KPIs): - the percentage of energy gain (which must be the highest possible) - the number of :ref:`SLA violations ` (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 :ref:`Action Plan `. The efficacy also enables the :ref:`Administrator ` to objectively compare different :ref:`Strategies ` for the same goal and same workload of the :ref:`Cluster `. .. _project_definition: Project ======= :ref:`Projects ` represent the base unit of “ownership” in OpenStack, in that all :ref:`resources ` in OpenStack should be owned by a specific :ref:`project `. In OpenStack Identity, a :ref:`project ` must be owned by a specific domain. Please, read `the official OpenStack definition of a Project `_. .. _scoring_engine_definition: Scoring Engine ============== .. watcher-term:: watcher.api.controllers.v1.scoring_engine .. _sla_definition: SLA === :ref:`SLA ` means Service Level Agreement. The resources are negotiated between the :ref:`Customer ` and the Cloud Provider in a contract. Most of the time, this contract is composed of two documents: - :ref:`SLA ` : Service Level Agreement - :ref:`SLO ` : Service Level Objectives Note that the :ref:`SLA ` is more general than the :ref:`SLO ` 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 :ref:`SLO ` 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_definition: SLA violation ============= A :ref:`SLA violation ` happens when a :ref:`SLA ` defined with a given :ref:`Customer ` could not be respected by the cloud provider within the timeframe defined by the official contract document. .. _slo_definition: SLO === A Service Level Objective (SLO) is a key element of a :ref:`SLA ` between a service provider and a :ref:`Customer `. 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_definition: Solution ======== .. watcher-term:: watcher.decision_engine.solution.base .. _strategy_definition: Strategy ======== .. watcher-term:: watcher.api.controllers.v1.strategy .. _watcher_applier_definition: Watcher Applier =============== .. watcher-term:: watcher.applier.base .. _watcher_database_definition: 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 :doc:`architecture` for more details on this component. .. _watcher_decision_engine_definition: Watcher Decision Engine ======================= .. watcher-term:: watcher.decision_engine.manager .. _watcher_planner_definition: Watcher Planner =============== .. watcher-term:: watcher.decision_engine.planner.base