Thank you for starting this! On Fri, Dec 13, 2019 at 2:48 AM melanie witt <melwittt@gmail.com> wrote:
Hey all,
Recently I'm trying to figure out how to fulfill a use case in the nova ironic driver around treating an ironic node's 'cpu_arch' as optional.
This is coming up as a result of a downstream issue [1] and recent change on the ironic side [2] to make cpu_arch optional for iscsi deployments. The change makes it so that ironic will _not_ include a 'cpu_arch' attribute as part of a node's properties if iscsi.
On the nova side, we have a filter scheduler ImagePropertiesFilter which will only match a node if the architecture, hypervisor_type, and vm_mode in the glance image properties match the cpu_arch of the node. We have always pulled the cpu_arch of the from the ironic node properties since the original ironic driver code was added to nova.
Now, the use case I'm trying to solve today [3] is where an iscsi ironic deployment has no cpu_arch specified on the ironic side and the deployer wants to use glance images with architecture specified in their image properties. Today (and historically always) the request to create an instance in this situation will fail with NoValidHost because the nova ironic driver could not determine a cpu_arch from the ironic node.
I tend to think that if the image requires an explicit architecture, we should keep failing. However, hypervisor_type==baremetal should probably be a valid case (and I don't really know what vm_mode is, so cannot comment here).
My questions are:
* Is this a valid thing to want to do?
* If if is valid, what is the correct way that we should handle missing cpu_arch in the nova ironic driver? Should we guess at a default cpu_arch? If so, how? Or should we add a new config option where a default cpu_arch can be specified? Or, other?
Worst case, we can document cpu_arch as being required for nova. A bit inconvenient, but certainly not the end of the world. Dmitry
Thanks in advance for any input you can offer.
Cheers, -melanie
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1653788 [2] https://review.opendev.org/620634 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1688838