I feel there are lot of moving parts to this problem.
Currently, I see a discrepancy in the way the NoValidHost exception is being handled/generated.
The amount of information - we would like to provide to this exception are philosophically different and different parts of the code.
In the nova/scheduler/utils.py method - it appears that when the retries exceed the max_attempts - we are putting out a lot of information in the NoValidHost exception:
I feel there are lot of moving parts to this problem.
Currently, I see a discrepancy in the way the NoValidHost exception is being handled/generated.
The amount of information - we would like to provide to this exception are philosophically different and different parts of the code.
In the nova/scheduler/ utils.py method - it appears that when the retries exceed the max_attempts - we are putting out a lot of information in the NoValidHost exception:
https:/ /github. com/openstack/ nova/blob/ master/ nova/scheduler/ utils.py# L165
However, at the same time, in https:/ /github. com/openstack/ nova/blob/ master/ nova/scheduler/ filter_ scheduler. py#L79 ,
we seem to say - that - we shouldn't be putting out too much information.
Upon chatting with bauzas on IRC, it sounds like - we need a discussion for this at the summit.