I was bit investigating the reason already and I found out the reason why nova-compute's enable_new_service was ignored. Currently we can not configure that option per host but per conductor that nova-compute will use for database access. This is not what document said and it's un-useful because this bahaviour prevent us from configuring enable_new_service option per host, So probably this should be recognised as bug
So this bug report will raise 2 problems.
* The enable_new_services option should be evaluated in each service(binary)
* The description of that option is not How actually works
* Nova seems intentionally limit that option being valid for only nova-compute
* But description said we can configure for all services
Steps to reproduce
==================
Just deployed OpenStack somehow
* Stop nova-compute on HOST1
* Change enable_new_services configuration from True to False in nova-compute on HOST1
* nova-compute service on HOST1 is deleted by CLI
* nova-compute is started on HOST1
Expected result
===============
* nova-compute service on HOST1 is registered as disabled service
Actual result
=============
* nova-compute service on HOST1 is registered as enable service
The root cause of this
=============
CONF.enable_new_services is referred in db/sqlalchemy/api.py where is just before try to access to database, which means if service(binary) is using nova-conductor for database access, CONF.enable_new_services configuration is not referred in that process to issue database access task and always nova-conductor's CONF.enable_new_services will be referred for these service.
That's why nova-compute's enable_new_services option is not enforced in above case.
Description
===========
If we believe ocata configuration reference (https:/ /docs.openstack .org/ocata/ config- reference/ compute/ config- options. html), the enable_new_services option should be able to be configured per service per host.
But even if I updated nova.conf for "nova-compute", that option value is always ignored.
I was bit investigating the reason already and I found out the reason why nova-compute's enable_new_service was ignored. Currently we can not configure that option per host but per conductor that nova-compute will use for database access. This is not what document said and it's un-useful because this bahaviour prevent us from configuring enable_new_service option per host, So probably this should be recognised as bug
So this bug report will raise 2 problems.
* The enable_new_services option should be evaluated in each service(binary)
* The description of that option is not How actually works
* Nova seems intentionally limit that option being valid for only nova-compute
* But description said we can configure for all services
Steps to reproduce
==================
Just deployed OpenStack somehow
* Stop nova-compute on HOST1
* Change enable_new_services configuration from True to False in nova-compute on HOST1
* nova-compute service on HOST1 is deleted by CLI
* nova-compute is started on HOST1
Expected result
===============
* nova-compute service on HOST1 is registered as disabled service
Actual result
=============
* nova-compute service on HOST1 is registered as enable service
The root cause of this
=============
CONF.enable_ new_services is referred in db/sqlalchemy/ api.py where is just before try to access to database, which means if service(binary) is using nova-conductor for database access, CONF.enable_ new_services configuration is not referred in that process to issue database access task and always nova-conductor's CONF.enable_ new_services will be referred for these service.
That's why nova-compute's enable_new_services option is not enforced in above case.