Open Stack

On Fri, Dec 13, 2019 at 4:34 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> 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.
>

Now that I understand where this entire discussion is coming from,..
there seems to be a strong desire among some of the larger operators
(and kind of has been) to be able to have one ironic or as few ironics
to manage their hardware fleet as possible. So I'm not sure how well
it would work if it is always required that they create the cpu arch
field. Then again, most of these deployments use inspector to also do
wiring and system configuration validation prior to deployment, so
they would have cpu_arch then.... Hmmm, this is a conundrum.


> 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
>>