Open Stack

Hi everyone,

we are developing an Ironic driver for OneView [1], an Infrastructure 
Management System (IMS) by HP and, in order to deploy the node 
correctly, the driver needs to know some specific information about the 
configuration of the physical hardware.

In OneView, there is the concept of a "Server Profile", which contains 
information about the hardware configuration, like boot order, bios 
settings, network connections, firmware version, storage information 
etc. There are 150+ parameters. A Server Profile has to be assigned to 
the physical hardware before it is powered on. In this way we can make 
sure that a node is provisioned, connected to the correct network and 
using the correct storage, for example.

Therefore, to make a deployment, the driver needs to know which Server 
Profile to use as different Server Profiles can be applied to the same 
hardware type.

Our first thought was to abstract these options (the possible Server 
Profiles) into different flavors, since it contains configurations that 
can be used even to change the ammount of disk a server has (using SAN 
volumes), or the power configuration it will use. Nova flavors do have a 
'capabilities' namespace on the extra_specs field which can be used to 
pass additional information to be used by the driver, but the data in 
this namespace is mandatorily used on node matching by the Nova 
scheduler when the capability filter is used (which is default and 
important).

In our case, the driver requires additional information regarding the 
Server Profile that is contained on the flavor, but that should *not* be 
used in scheduling (since a single node could accept a number of 
different profiles).

We suggested to use a 'passthrough' namespace (note that no changes are 
required on Nova to do that) in the flavor extra_specs and update the 
Ironic's patcher (here we have a simple change in Ironic Virt Driver, 
only) to include this information in the instance_info field for the 
node, but, according to some team members of Nova, this is directly in 
conflict their goals of abstracting the compute resources that Nova 
provide.

Another option, suggested by dansmith, is to solve this problem in 
Ironic using a "reservation" concept (created on Ironic to abstract such 
information) and pass the type of reservation on "nova boot", avoiding 
changes that could hurt the flavor concept. We think the footprint of 
such a change, not only to Ironic, but on Nova, python-novaclient and 
Horizon would be huge.

Nisha sent a spec about modify the nova-ironic-virt-driver to accept the 
json lists and dictionaries as valid values for the ironic 
node.properties['capabilities'] [2]. But, in this case the idea is not a 
solution to our scenario, because we need to pass information that 
should not be matched during the scheduling task.

Do you see another way to approach this problem? We hope that, with your 
help, we'll find out an solution that will solve our problem without 
contradicting any principle the nova team has set.

Thank you in advance!
Sinval Vieira

[1] 
http://www8.hp.com/br/pt/business-solutions/converged-systems/oneview.html
[2] https://review.openstack.org/#/c/182572