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.li...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
