Weird behavior of enable_new_services in nova.conf

If you are running OpenStack in production, probably you could face the situation that you want some new hypervisor to be registered with disabled state at first and after a while you want to enable these manually for some reason.

That use case is completely reasonable and actually nova already recognise that use case and provide option for the operator to control initial state enabled or disabled being used when new service is registered.

enable_new_services = True

(Boolean) Enable new services on this host automatically.

When a new service (for example “nova-compute”) starts up, it gets registered in the database as an enabled service. Sometimes it can be useful to register new services in disabled state and then enabled them at a later point in time. This option can set this behavior for all services per host.

Possible values:

True: Each new service is enabled as soon as it registers itself.

False: Services must be enabled via a REST API call or with the CLI with nova service-enable <hostname> <binary>, otherwise they are not ready to use.

quoted from https://docs.openstack.org/ocata/config-reference/compute/config-options.html

But actually this “enable_new_services” option is a bit tricky and this have 3 outstanding behaviors not being mentioned in document but you have to know if you use this.

1. This option can only be enforced against nova-compute by design
2. This option should be configured on nova-conductor not nova-compute
3. This option can not be configured per host

1. This option can only be enforced against nova-compute by design

Although the document said we can configure “enable_new_services” for all services per host, but it seems intentionally limit to be used for nova-compute as long as I read unit test (https://github.com/openstack/nova/blob/stable/pike/nova/tests/unit/db/test_db_api.py#L3517-L3535). This unit test definitely make sure that option can only be valid for nova-compute.

That’s why I said this behavior is by design.

2. This option should be configured on nova-conductor not nova-compute

This is the probably bug. Actually this limitation cause third limitation as well. If you have a experience to change nova.conf for nova-compute and try to use enable_new_services options, you probably already notice enable_new_services is ignored.

The reason of that is CONF.enable_new_services is referred in nova/db/sqlalchemy/api.py instead of Service class which is entry point of all daemon like nova-compute, nova-schedule….

As you know nova-compute doesn’t connect to database directly and always access via nova-conductor but Service(nova-compue) doesn’t take care of these and mean to access the database object as usually via object. But this object instance method is decorated with \@base.remotable and that decorator change the behavior from evaluating the method to pass object onto nova-conductor and ask nova-condutor to execute that method nova-compute was going to evaluate and then nova-conductor will continue on evaluating the method and eventually check CONF.enable_new_services and create service entity on database. This is the why enable_new_services option should be configured on nova-conductor.

If you can not understand what I’m talking about, probably this article First step for reading Nova source will help.

3. This option can not be configured per host

As already mentioned in second limitation , the limitation that enable_new_service should be configured on nova-conductor make obviously operator impossible to configure enable_new_service per host.

Conclusion

It’s no point if I just murmur a complaint at such a behavior, So I created the bugs ticket here and actually already submit the patch(bug/1747484) to relieve second,third limitations. As for first limitation, this seems intentionally implemented, So I won’t do anything and I understood why the developer limit to nova-compute.

Until above patch merged into upstream, you have to configure enable_new_services on nova-conductor if you want to use or apply patch(bug/1747484) and build your own package.