Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

2015-03-03 Thread Joe Cropper

 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


Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

2015-03-03 Thread Jay Pipes

On 03/03/2015 06:55 AM, Joe Cropper wrote:

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?


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?

2015-03-03 Thread Joe Cropper
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 jaypi...@gmail.com wrote:
 
 On 03/03/2015 06:55 AM, Joe Cropper wrote:
 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?
 
 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?

2015-03-03 Thread Vishvananda Ishaya
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