<div dir="ltr"><div><div><div>Hi Phil et al,<br><br></div><div>Thanks for the great feedback.<br></div><div><br></div>I can see the 'reason for disabled' patch as a usable work around. I'm sad that it's a hassle to get the patch in, but I'm glad to see I'm not the only one that happens to. I'm still getting used to the openstack commit process. It's a lot more political than I've ever seen before, but it is producing high quality code for sure.<br>
</div><div><br></div>The availability_zone scheduler filter also looks useful as a replacement.<br><br></div><div>The only concern I have if we were to use those, would be the race condition, where a migration starts towards the host, then you set it to disabled. I'm not sure if that's possible, but I can imagine a sysadmin setting it a host to spare and walking away, then later using it for a chassis swap, then some customer saying, 'dude! <a href="http://mybigsite.com">mybigsite.com</a> is down'.<br>
<br>I'll investigate the possibility of the race condition happening, but if anyone already knows the answer, you could save me some work ;)<br><br>Many Thanks,<br>Matthew Sherborne<br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Mar 25, 2013 at 8:54 PM, Belmiro Moreira <span dir="ltr"><<a href="mailto:moreira.belmiro.email.lists@gmail.com" target="_blank">moreira.belmiro.email.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matthew,<br>
for "spare" compute nodes we are using what Phil said.<br>
The difference that I see in your blueprint is that a "spare host will be guaranteed not to have any VMs".<br>
An this is not true if we disable the nova-compute service.<br>
<br>
Instead, couldn't we have a flag in nova that guarantees (or not) this behaviour in disabled compute nodes?<br>
<br>
cheers,<br>
Belmiro<br>
<div class="HOEnZb"><div class="h5"><br>
On Mar 25, 2013, at 11:19 AM, "Day, Phil" <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>> wrote:<br>
<br>
> Hi Matthew,<br>
><br>
> Doesn’t just setting “enable_new_services=False” give you what you want ?<br>
><br>
> We run this on all of our servers so that any newly installed systems can be checked before they are allowed to start hosting Instances. Couple that with a change we’ve been trying to get through for a while now to add a short text field to the services to capture what they are disabled (<a href="https://review.openstack.org/#/c/10877/" target="_blank">https://review.openstack.org/#/c/10877/</a> ) and you could just set the reason field to “Spare” on the ones you decide not to enable.<br>
><br>
> Cheers,<br>
> Phil<br>
><br>
> From: Matthew Sherborne [mailto:<a href="mailto:msherborne@gmail.com">msherborne@gmail.com</a>]<br>
> Sent: 22 March 2013 16:28<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] blueprint for 'spare-hosts'<br>
><br>
> All comments appreciated.<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/spare-hosts" target="_blank">https://blueprints.launchpad.net/nova/+spec/spare-hosts</a><br>
><br>
> In summary, when one sets up a nova install, they can set some of the machines to spare.<br>
><br>
> Spare means disabled plus the guarantee that there are no customer vms running on there.<br>
><br>
> It differs from maintenance mode in that setting a spare that has VMs on it, will just fail, rather than cause a migration.<br>
><br>
> Spare machines can be used for quick chassis swaps or can be enabled to receive an emergency migration, or when an end user needs more space than was initially planned.<br>
><br>
> Having 'spare' machines in your install a useful safety buffer to let you know when to start adding more.<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Blueprint-spare-hosts#Possible_later_additions" target="_blank">https://wiki.openstack.org/wiki/Blueprint-spare-hosts#Possible_later_additions</a><br>
><br>
> ----<br>
><br>
> Please comment on implementation ideas, additional features, and perceived usefulness.<br>
><br>
> Many Thanks,<br>
> Matthew Sherborne<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>