On 11/23/20 11:31 AM, Balázs Gibizer wrote:
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)
Let's say we apply the patch you're proposing, and that nova-compute isn't loaded anymore with the db credentials, because it's on a separate file, and nova-compute doesn't load it. In such scenario, the /etc/nova/nova-db.conf could still be present with db credentials filled-in. So, the patch you're proposing is still not effective for wrong configuration of nova-compute hosts.
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.
Because of the above, I very much think it'd be the best way to go, but I understand your point of view. Going to the /etc/nova/nova-db.conf and nova-api-db.conf thing is probably good anyways. As for the nova-conductor thing, I very much would prefer if we had a clean and explicit "superconductor=true" directive, with possibly some checks to display big warnings in the nova-conductor.log file in case of a wrong configuration. If we don't have that, then at least things must be extensively documented, because that's really not obvious what's going on. Cheers, Thomas Goirand (zigo)