The watcher.decision_engine.strategy.strategies.outlet_temp_control Module¶

Good Thermal Strategy

Towards to software defined infrastructure, the power and thermal intelligences is being adopted to optimize workload, which can help improve efficiency, reduce power, as well as to improve datacenter PUE and lower down operation cost in data center. Outlet (Exhaust Air) Temperature is one of the important thermal telemetries to measure thermal/workload status of server.

This strategy makes decisions to migrate workloads to the hosts with good thermal condition (lowest outlet temperature) when the outlet temperature of source hosts reach a configurable threshold.

class watcher.decision_engine.strategy.strategies.outlet_temp_control.OutletTempControl(config, osc=None)[source]¶

Bases: watcher.decision_engine.strategy.strategies.base.ThermalOptimizationBaseStrategy

[PoC] Outlet temperature control using live migration

Description

It is a migration strategy based on the outlet temperature of compute hosts. It generates solutions to move a workload whenever a server’s outlet temperature is higher than the specified threshold.

Requirements

• Hardware: All computer hosts should support IPMI and PTAS technology
• Software: Ceilometer component ceilometer-agent-ipmi running in each compute host, and Ceilometer API can report such telemetry hardware.ipmi.node.outlet_temperature successfully.
• You must have at least 2 physical compute hosts to run this strategy.

Limitations

• This is a proof of concept that is not meant to be used in production
• We cannot forecast how many servers should be migrated. This is the reason why we only plan a single virtual machine migration at a time. So it’s better to use this algorithm with CONTINUOUS audits.
• It assume that live migrations are possible

Spec URL

https://github.com/openstack/watcher-specs/blob/master/specs/mitaka/implemented/outlet-temperature-based-strategy.rst

calc_used_resource(node)[source]¶

Calculate the used vcpus, memory and disk based on VM flavors

choose_instance_to_migrate(hosts)[source]¶

Pick up an active instance to migrate from provided hosts

do_execute()[source]¶

Strategy execution phase

This phase is where you should put the main logic of your strategy.

filter_dest_servers(hosts, instance_to_migrate)[source]¶

Only return hosts with sufficient available resources

get_available_compute_nodes()[source]¶

classmethod get_config_opts()[source]¶

Defines the configuration options to be associated to this loadable

Returns:	A list of configuration options relative to this Loadable
Return type:	list of oslo_config.cfg.Opt instances

classmethod get_display_name()[source]¶

The goal display name for the strategy

classmethod get_name()[source]¶

The name of the strategy

classmethod get_schema()[source]¶

Defines a Schema that the input parameters shall comply to

Returns:	A jsonschema format (mandatory default setting)
Return type:	dict

classmethod get_translatable_display_name()[source]¶

The translatable msgid of the strategy

group_hosts_by_outlet_temp()[source]¶

Group hosts based on outlet temp meters

post_execute()[source]¶

Post-execution phase

This can be used to compute the global efficacy

pre_execute()[source]¶

Pre-execution phase

This can be used to fetch some pre-requisites or data.