Open Stack

Hi Phil et al,

Thanks for the great feedback.

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.

The availability_zone scheduler filter also looks useful as a replacement.

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! mybigsite.com is down'.

I'll investigate the possibility of the race condition happening, but if
anyone already knows the answer, you could save me some work ;)

Many Thanks,
Matthew Sherborne


On Mon, Mar 25, 2013 at 8:54 PM, Belmiro Moreira <
moreira.belmiro.email.lists at gmail.com> wrote:

> Hi Matthew,
> for "spare" compute nodes we are using what Phil said.
> The difference that I see in your blueprint is that a "spare host will be
> guaranteed not to have any VMs".
> An this is not true if we disable the nova-compute service.
>
> Instead, couldn't we have a flag in nova that guarantees (or not) this
> behaviour in disabled compute nodes?
>
> cheers,
> Belmiro
>
> On Mar 25, 2013, at 11:19 AM, "Day, Phil" <philip.day at hp.com> wrote:
>
> > Hi Matthew,
> >
> > Doesn’t just setting “enable_new_services=False” give you what you want ?
> >
> > 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
> (https://review.openstack.org/#/c/10877/  ) and you could just set the
> reason field to “Spare” on the ones you decide not to enable.
> >
> > Cheers,
> > Phil
> >
> > From: Matthew Sherborne [mailto:msherborne at gmail.com]
> > Sent: 22 March 2013 16:28
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] blueprint for 'spare-hosts'
> >
> > All comments appreciated.
> >
> > https://blueprints.launchpad.net/nova/+spec/spare-hosts
> >
> > In summary, when one sets up a nova install, they can set some of the
> machines to spare.
> >
> > Spare means disabled plus the guarantee that there are no customer vms
> running on there.
> >
> > It differs from maintenance mode in that setting a spare that has VMs on
> it, will just fail, rather than cause a migration.
> >
> > 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.
> >
> > Having 'spare' machines in your install a useful safety buffer to let
> you know when to start adding more.
> >
> >
> https://wiki.openstack.org/wiki/Blueprint-spare-hosts#Possible_later_additions
> >
> > ----
> >
> > Please comment on implementation ideas, additional features, and
> perceived usefulness.
> >
> > Many Thanks,
> > Matthew Sherborne
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130326/be89cd54/attachment.html>