> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya <vishvana...@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?

> 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


__________________________________________________________________________
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