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