Open Stack

On Tue, 2018-12-04 at 21:35 +0000, Chris Dent wrote:
> On Wed, 5 Dec 2018, Mike Carden wrote:
> 
> > On Tue, Dec 4, 2018 at 9:58 PM Chris Dent <cdent+os at anticdent.org> wrote:
> > 
> > > 
> > > * The 'randomize_allocation_candidates' config setting is used by
> > >    the placement-api process (probably called nova-placement-api in
> > >    queens), not the nova-scheduler process, so you need to update the
> > >    config (in the placement section) for the former and restart it.
> > 
> > I tried the same thing in the nova.conf of the nova_placement containers
> > and still no joy.
> 
> Darn.
> 
> > A check on a fresh deploy of Queens with just a couple of x86 compute nodes
> > proves that it can work without randomize_allocation_candidates being set
> > to True. Out of the box we get an even distribution of VMs across compute
> > nodes. It seems that somewhere along the path of adding Ironic and some
> > baremetal nodes and host aggregates and a PPC64LE node, the scheduling goes
> > awry.
> 
> Yeah, this sort of stuff is why I was hoping we could see some of
> your logs, to figure out which of those things was the haymaker.
so one thing that came up recently downstream was a discusion around the BuildFailureWeigher
https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
and the build_failure_weight_multiplier
https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.build_failure_weight_multiplier
i wonder if failed build shoudl be leading to packing behavior.

it would explain why intially it is fine but over time as host get a significant build failure weight applied that
the cluster transiation form even spread to packing behaivior.
> 
> If you figure it out, please post about it.
>