On Sat, Nov 21, 2020 at 02:47, Thomas Goirand <zigo@debian.org> wrote:
On 11/18/20 8:24 PM, Dan Smith wrote:
which things are _not_allowed_ to be set for a service (such as db credentials on the compute).
I still don't understand why this is forbidden.
Sure, I understand what people wrote: that it is a security problem.
Can't nova-compute just *ignore* the db credentials, and then everyone is done with it, and moves on? That's a much more easy way to handle this problem, IMO.
It is still a security problem if nova-compute ignores the config as the config still exists on the hypervisor node (in some deployment scenarios) There are two existing technical reasons too: * Nova uses the [api_database]connection config to determine if the client of the compute RPC runs on the top level (i.e. super conductor) or locally in a cell (i.e. cell conductor or a nova-compute). [1] * The fairly recent change[2] that prevents older that N-1 services to start also depends on the [api_database]connection config to determine the scope (global vs. cell local) of the query that gathers the current service level of the cluster. I don't think that the [api_database]connection dependency can be removed from the super-conductor and cell-conductor differentiation perspective. From the nova-compute perspective we might be able to replace the [api_database]connection dependency with some hack. E.g to put the service name to the global CONF object at the start of the service binary and depend on that instead of other part of the config. But I feel pretty bad about this hack. Cheers, gibi [1] https://github.com/openstack/nova/blob/e16800cc0aebf1174c5c0b6c4b043b0962252... [2] https://github.com/openstack/nova/blob/e16800cc0aebf1174c5c0b6c4b043b0962252...
Cheers,
Thomas Goirand (zigo)