I’m pretty sure it has always done this: leave the host set on the final 
scheduling attempt. I agree that this could be cleared which would free up room 
for future scheduling attempts.

Vish

On Mar 3, 2015, at 12:15 AM, Joe Cropper <cropper....@gmail.com> wrote:

> Hi Folks,
> 
> I was wondering if anyone can comment on the intended behavior of how 
> instance.host is supported to be set during reschedule operations.  For 
> example, take this scenario:
> 
> 1. Assume an environment with a single host… call it host-1
> 2. Deploy a VM, but force an exception in the spawn path somewhere to 
> simulate some "hypervisor error”
> 3. The scheduler correctly attempts to reschedule the VM, and ultimately ends 
> up (correctly) with a NoValidHost error because there was only 1 host
> 4. However, the instance.host (e.g., [nova show <vm>]) is still showing 
> ‘host-1’ — is this the expected behavior?
> 
> It seems like perhaps the claim should be reverted (read: instance.host 
> nulled out) when we take the exception path during spawn in step #2 above, 
> but maybe I’m overlooking something?  This behavior was observed on a Kilo 
> base from a couple weeks ago, FWIW.
> 
> Thoughts/comments?
> 
> Thanks,
> Joe
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to