Hide Forgot
Description of problem: At the moment, we only set scheduler_max_attempts=3 in nova.conf (default). Given that we have a design problem between Ironic and Nova, we most of time end up with some undercloud provisioning failing because the placement is suboptimal and we hit a upper bound of retries. Increasing that retry number doesn't really fix the problem but it's a nice workaround for helping customers to deploy Director. Since we can't really assume which max number we should cap the number of retries, we should ideally try to figure out the number of hosts to provision in the undercloud and set that number as a value for scheduler_max_attempts.
Hi! I don't think we can realistically reconfigure Nova just before deployment (it will even require root access). So I think increasing the retries number e.g. to 30 would do the trick. Anyway I know that people prefer to deploy in bulks of 20-30.
Upstream patch posted.
Patches merged upstream, waiting for the next rebase now.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Sigh, I'm so bad at updating my bugs.... Mike, I'm sorry again, this bug did make it in OSPd8...
(In reply to Dmitry Tantsur from comment #2) > Hi! I don't think we can realistically reconfigure Nova just before > deployment (it will even require root access). So I think increasing the > retries number e.g. to 30 would do the trick. Anyway I know that people > prefer to deploy in bulks of 20-30. Verified with ospd-9 [stack@undercloud72 ~]$ rpm -qa | grep undercloud instack-undercloud-4.0.0-2.el7ost.noarch vi /etc/nova/nova.conf # * Services that use this: # # ``nova-scheduler`` # # * Related options: # # None # (integer value) #scheduler_max_attempts=3 scheduler_max_attempts=30