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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
