Open Stack

On Mon, Sep 15, 2014 at 10:51 AM, Jay Faulkner <jay at jvf.cc> wrote:
> Steven,
>
> It's important to note that two of the blueprints you reference:
>
> https://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt
> https://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery
>
> are both very unlikely to land in Ironic -- these are configuration and discovery pieces that best fit inside a operator-deployed CMDB, rather than Ironic trying to extend its scope significantly to include these type of functions. I expect the scoping or Ironic with regards to hardware discovery/interrogation as well as configuration of hardware (like I will outline below) to be hot topics in Ironic design summit sessions at Paris.
>
> A good way of looking at it is that Ironic is responsible for hardware *at provision time*. Registering the nodes in Ironic, as well as hardware settings/maintenance/etc while a workload is provisioned is left to the operators' CMDB.
>
> This means what Ironic *can* do is modify the configuration of a node at provision time based on information passed down the provisioning pipeline. For instance, if you wanted to configure certain firmware pieces at provision time, you could do something like this:
>
> Nova flavor sets capability:vm_hypervisor in the flavor that maps to the Ironic node. This would map to an Ironic driver that exposes vm_hypervisor as a capability, and upon seeing capability:vm_hypervisor has been requested, could then configure the firmware/BIOS of the machine to 'hypervisor friendly' settings, such as VT bit on and Turbo mode off. You could map multiple different combinations of capabilities as different Ironic flavors, and have them all represent different configurations of the same pool of nodes. So, you end up with two categories of abilities: inherent abilities of the node (such as amount of RAM or CPU installed), and configurable abilities (i.e. things than can be turned on/off at provision time on demand) -- or perhaps, in the future, even things like RAM and CPU will be dynamically provisioned into nodes at provision time.
>


Thanks for the explanation, Jay.

Steven, in response to your question "[what would] just do that
optimization before the deployment?" -- see Jay's example above. This
path has grown out of several discussions we've had over the last two
years, and is closer aligned to what I *thought* TripleO wanted back
when I was more involved in that project.

To paraphrase: Ironic exposes "capabilities" to Nova, and the Nova
scheduler can pick a node based on which capability is requested in
the flavor definition. We don't yet, but are planning to, support
on-demand customization of nodes based on the requested capabilities.
Toggling the VT bit is a canonical example of this -- we should be
able to dynamically update a node's firmware configuration to satisfy
both virtualization and non-virtualization workloads. That's going to
be expressed via Nova flavors and communicated at provision time by
Nova to Ironic. Eventually, I'd like to see everything in that space
(except perhaps RAID topology, since that actually takes a lot of time
to change).

-Devananad