On Mon, Sep 15, 2014 at 10:51 AM, Jay Faulkner <j...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
