Open Stack

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> 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
> 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/2019d755/attachment.html>