I had to re-learn why this part of comment 2 isn't a problem:
"""
The only thing I can figure is maybe you have the max_attempts config option value set to 1 or you're forcing the host/node during the server create?
In that case we don't set the retry entry in filter_properties.
"""
That's because if CONF.scheduler.max_attempts=1 or force_hosts/nodes, we don't set the 'retry' entry in the filter_properties dict passed between conductor and compute:
I had to re-learn why this part of comment 2 isn't a problem:
"""
The only thing I can figure is maybe you have the max_attempts config option value set to 1 or you're forcing the host/node during the server create?
https:/ /github. com/openstack/ nova/blob/ 39b05ee9e34ae7e 7c1854439f88758 8ec157bc69/ nova/scheduler/ utils.py# L634
In that case we don't set the retry entry in filter_properties.
"""
That's because if CONF.scheduler. max_attempts= 1 or force_hosts/nodes, we don't set the 'retry' entry in the filter_properties dict passed between conductor and compute:
https:/ /github. com/openstack/ nova/blob/ 536e5fa57f72f71 217fd9f2160df02 84a76102e1/ nova/scheduler/ utils.py# L638
And then if we hit a build failure in compute, we don't cast back to the cell conductor to reschedule, we just fail:
https:/ /github. com/openstack/ nova/blob/ 536e5fa57f72f71 217fd9f2160df02 84a76102e1/ nova/compute/ manager. py#L1825
So if we get here in conductor during a reschedule:
https:/ /github. com/openstack/ nova/blob/ 536e5fa57f72f71 217fd9f2160df02 84a76102e1/ nova/conductor/ manager. py#L585
The 'retry' key is going to be set and num_attempts won't be 1.