Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?
Logged a bug [1] and submitted a fix [2]. Review away! [1] https://bugs.launchpad.net/nova/+bug/1427944 [2] https://review.openstack.org/#/c/161069/ - Joe > On Mar 3, 2015, at 4:42 PM, Jay Pipes wrote: > > On 03/03/2015 06:55 AM, Joe Cropper wrote: >>> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya >>> 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? > > Seems like a bug to me. Feel free to create one in Launchpad and we'll get on > it. > > Best, > -jay > > __ > 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
Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?
On 03/03/2015 06:55 AM, Joe Cropper wrote: On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya 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? Seems like a bug to me. Feel free to create one in Launchpad and we'll get on it. Best, -jay __ 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
Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?
> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya 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 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 ]) 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
Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?
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 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 ]) 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
