Open Stack

Thank you for starting this!

On Fri, Dec 13, 2019 at 2:48 AM melanie witt <melwittt at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191213/b0f916f8/attachment.html>