Basically, we accepted to not verify the scheduler in case of a rebuild because it was staying with the compute node. What we missed is that in case people pass a different image, then it could be something not acceptable for the scheduler.
Is that a security issue ? Probably. Should it be embargoed ? Not sure, but I leave other commenting that.
About the possible solution, I think we could easily mimic the evacuate behaviour and use the RequestSpec.requested_destination field for calling the scheduler but only for that specific host.
Yeah, the bug is latent since https:/ /github. com/openstack/ nova/commit/ d6ca1cc02ab5861 5a6bb1b337db34d d06525112e
Basically, we accepted to not verify the scheduler in case of a rebuild because it was staying with the compute node. What we missed is that in case people pass a different image, then it could be something not acceptable for the scheduler.
Is that a security issue ? Probably. Should it be embargoed ? Not sure, but I leave other commenting that.
About the possible solution, I think we could easily mimic the evacuate behaviour and use the RequestSpec. requested_ destination field for calling the scheduler but only for that specific host.
See https:/ /github. com/openstack/ nova/blob/ 93bf6ba5186a366 3606aa843a2f247 709173f073/ nova/compute/ api.py# L3977-L3994 where we set that field if the operator doesn't want to force the target.