build baremetal data model in watcher

For a data center with large amount of VMs and physical hosts,the total power consumption is tremendous. When workload is not heavy, Watcher can be used to reduce power consumption by triggering a request to power off some idle hosts without VMs. And when the workload increases Watcher will trigger a “power on” request to fulfill the service requirements.

This “energy saving” goal can be fulfilled by adding four features in Watcher: 1) Build a new baremetal data model within current Watcher Cluster Data Model 2) Add new actions “power on” and “power off” in Watcher 3) Implement a new strategy based on ‘baremetal’ and ‘compute’ data models, which could trigger ‘compute’ and ‘baremetal’ actions. 4) Update the bare metal data model by ironic notifications

This spec implements the first feature: Build a new baremetal (ironic) data model independent from current Watcher Cluster Data Model.

Problem description

In the “power on” and “power off” actions, Watcher sends request to power on/off physical machines managed by nova using ironic (ironic calling IPMI tools). So watcher should know the hypervisor_id and node_uuid of the target host(s), as well as their mapping list. In this spec, we will build a baremetal data model in watcher to describe this mapping list between hypervisor_id and node_uuid

Let’s take an example, if we need to power off host 3 and 4 as shown in the following list. But watcher doesn’t know their node_uuid.

[root@host_192_51_151_2 ~(keystone_admin)]# nova hypervisor-list +—-+———————+——-+———+ | ID | Hypervisor hostname | State | Status | +—-+———————+——-+———+ | 3 | host_192_51_151_3 | up | enabled | | 4 | host_192_51_151_5 | up | enabled | | 5 | host_192_51_151_7 | up | enabled | | 7 | host_192_51_151_8 | up | enabled | | 9 | host_192_51_151_9 | up | enabled | | 11 | host_192_51_151_10 | up | enabled | +—-+———————+——-+———+

So we establish a mapping list between hypervisor_id and node_uuid. Just like the following: +—-+———————+————————————–+———+ | ID | Hypervisor hostname | node_uuid | Extra | +—-+———————+————————————–+———+ | 3 | host_192_51_151_3 | 4f37180e-c310-4327-a286-d5ab9ffc6497 | | | 4 | host_192_51_151_5 | 4f37180e-c310-4327-a286-d5ab9ffc6498 | | | 5 | host_192_51_151_7 | 4f37180e-c310-4327-a286-d5ab9ffc6499 | | | 7 | host_192_51_151_8 | 4f37180e-c310-4327-a286-d5ab9ffc6500 | | | 9 | host_192_51_151_9 | 4f37180e-c310-4327-a286-d5ab9ffc6501 | | | 11 | host_192_51_151_10 | 4f37180e-c310-4327-a286-d5ab9ffc6502 | | +—-+———————+————————————–+———+

The “Extra” field is served as an extensible field.

Above all, from a watcher user’s perspective, the whole procedure starts from getting by ‘nova hypervisor-list’, then create ironic node manually using ‘ironic node create’ as described in the proposed change part. In the second step, the ironic_node_id is generated and the correlation is built. Given all these id and correlation information, now we can create a “power on and off” audit in watcher to do the optimization.

Use Cases

As a developer, I want to have a new baremetal data model independant from compute CDM in watcher to get the mapping list between hypervisor_id and ironic node_uuid.

Proposed change

  1. Add “” info into Ironic node “extra” field when create nodes or update nodes info. Just like the following two ways:

  • If we can not get before creating ironic node. 1) ironic node-create 2) nova hypervisor-list 3) ironic node-update

  • If we can get before creating ironic node. 1) nova hypervisor-list 2) ironic node-create

ironic node-create [-c <chassis>]

-d <driver> [-i <key=value>] [-p <key=value>] [-e <key=value>] [-u <uuid>] [-n <name>] [–network-interface <network_interface>] [–resource-class <resource_class>]

ironic node-create -d your_driver agent_ipmitool

-i ipmi_address=<ipmi_ip> -i ipmi_username=<ipmi_username> -i ipmi_password=<ipmi_password> -e -u ironic_node_uuid is the compute node ID saved in CCDM (Compute Cluster Data Model)

2) On watcher, build the Baremetal Cluster Data Model (BCDM) by periodically requesting Ironic service. The Baremetal Cluster Data Model structure is shown as followings


“uuid”: “4f37180e-c310-4327-a286-d5ab9ffc6497”, “power_state”: “power on”, “maintenance”: false, “maintenance_reason”: null, “extra”: {“compute_node_id”: 1} }



Data model impact


REST API impact


Security impact


Notifications impact

Watcher consumes some Ironic notifications. We leave this for future work, which is described in the following bp:

Other end user impact

Watcher may report a stale representation of the Ironic resources and to reduce this staleness, they can reduce the syncing interval in the configuration.

Performance Impact


Other deployer impact


Developer impact




Primary assignee:


Other contributors:


Work Items

  • Add baremetal data model.




Unit test on the Watcher Decision Engine. Tempest.

Documentation Impact

System Architecture doc will be updated, since model drivers accesses only nova and glance as of now.





Release Name