[openstack-dev] [nova] Intended behavior for instance.host on reschedule?
cropper.joe at gmail.com
Tue Mar 3 14:55:53 UTC 2015
> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
> 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.
Thanks Vish for the comment. Do we know if this is an intended feature or would we consider this a bug? It seems like we could free this up, as you said, to allow room for additional VMs, especially since we know it didn’t successfully deploy anyway?
> On Mar 3, 2015, at 12:15 AM, Joe Cropper <cropper.joe at 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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev