----- Original message -----
From: "Clark Boylan" <cboylan@sapwetik.org>
To: "Jeremy Stanley" <fungi@yuggoth.org>, openstack-discuss@lists.openstack.org
Cc: "Venkata Krishna Reddy" <Venkata.Krishna.Reddy@ibm.com>
Subject: [EXTERNAL] Re: Devstack stack run issue
Date: Tue, Oct 26, 2021 10:49 PM
 

On Tue, Oct 26, 2021, at 10:05 AM, Jeremy Stanley wrote:
> [keeping originator in Cc since they don't seem to be subscribed]
>
> On 2021-10-26 16:54:49 +0000 (+0000), Venkata Krishna Reddy wrote:
>> While running stack on latest devstack, ended up with the
>> following error message:
> [...]
>> Oct 26 16:36:49 ubuntu nova-compute[337228]: ERROR
>>     oslo_service.service nova.exception.InvalidCPUInfo: Configured
>>     CPU model: Nehalem is not compatible with host CPU. Please
>>     correct your config and try again. Unacceptable CPU info: CPU
>>     doesn't have compatibility.
>>
>> A week ago, the stack was successful and it is failing now.
> [...]
>
> This is due to https://review.opendev.org/815020  which merged a week
> ago to update the default CPU model in DevStack with one which will
> work for CentOS 9. See also this mailing list post and its replies
> which go into greater detail on the situation:
>
> http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025500.html 
>
> You can probably override LIBVIRT_CPU_MODEL in your configuration
> setting the old default of "none" if you want the old behavior for
> now, though there are likely better long-term solutions.

You would need to set LIBVIRT_CPU_MODE to "none" then LIBVIRT_CPU_MODEL should be ignored (note MODE vs MODEL). If that doesn't work it is a bug and we should fix it.

The other thing that might be worth double checking on is what CPU you are running devstack on. We expected that this would work for any reasonably new x86 based system. Aarch64 has an explicit override for the MODEL later in the code. I suppose it is possible we broke this for powerpc and need to add an explicit override similar to aarch64? If you are on x86 more details about the specific CPU might be useful to determine if there are problems with the expected Nehalem compatibility.

Clark