Open Stack

+1 as well, for the same reasons.  I also added by +1 to the review.  Thanks!


From: Alex Leonhardt <aleonhardt.py at gmail.com<mailto:aleonhardt.py at gmail.com>>
Date: Thursday, January 15, 2015 at 1:02 AM
To: Belmiro Moreira <moreira.belmiro.email.lists at gmail.com<mailto:moreira.belmiro.email.lists at gmail.com>>, OpenStack Operators <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] New services disable reason


Our install is still quite small and we take the risk of hitting that compute node whilst the service is starting,  but we haven't actually encountered that yet (probably a user base size issue) ...

IMHO, having a reason why stuff is disabled avoids hours of confusion and trying to find the person who 'did it'.

In terms of keeping track, I'd have thought that the dashboard admin panel can show you service states and I'd expect a disabled service to say 'disabled', but again we don't even use this feature at the moment.

+1 from me :)

Alex

On Wed, 14 Jan 2015 19:34 Belmiro Moreira <moreira.belmiro.email.lists at gmail.com<mailto:moreira.belmiro.email.lists at gmail.com>> wrote:
Hi,
as operators I would like to have your comments/suggestions on:
https://review.openstack.org/#/c/136645/1


With a large number of nodes several services are disabled because various reasons (in our case mainly hardware interventions).
To help operations we use the "disable reason" as fast filter to identify why the service is disabled.

At same time, we add several new nodes (nova-compute) per week.
At CERN to avoid adding a service when the daemon starts for the first time nova is configured with:
enable_new_services=False
This is great, however no "disable reason" is set.
For us having services disabled with no reason specified creates additional checks.

How are others keeping track of disabled services?


Belmiro
---
CERN
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150115/e3089088/attachment.html>