[nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service
jpena at redhat.com
Thu Nov 12 11:09:20 UTC 2020
> On 11/11/20 5:35 PM, Balázs Gibizer wrote:
> > Dear packagers and deployment engine developers,
> > Since Icehouse nova-compute service does not need any database
> > configuration as it uses the message bus to access data in the database
> > via the conductor service. Also, the nova configuration guide states
> > that the nova-compute service should not have the
> > [api_database]connection config set. Having any DB credentials
> > configured for the nova-compute is a security risk as well since that
> > service runs close to the hypervisor. Since Rocky nova-compute
> > service fails if you configure API DB credentials and set upgrade_level
> > config to 'auto'.
> > Now we are proposing a patch that makes nova-compute fail at startup
> > if the [database]connection or the [api_database]connection is
> > configured. We know that this breaks at least the rpm packaging, debian
> > packaging, and puppet-nova. The problem there is that in an all-in-on
> > deployment scenario the nova.conf file generated by these tools is
> > shared between all the nova services and therefore nova-compute sees DB
> > credentials. As a counter-example, devstack generates a separate
> > nova-cpu.conf and passes that to the nova-compute service even in an
> > all-in-on setup.
> > The nova team would like to merge  during Wallaby but we are OK to
> > delay the patch until Wallaby Milestone 2 so that the packagers and
> > deployment tools can catch up. Please let us know if you are impacted
> > and provide a way to track when you are ready with the modification that
> > allows  to be merged.
> > There was a long discussion on #openstack-nova today around this
> > topic. So you can find more detailed reasoning there.
> > Cheers,
> > gibi
> IMO, that's ok if, and only if, we all agree on how to implement it.
> Best would be if we (all downstream distro + config management) agree on
> how to implement this.
> How about, we all implement a /etc/nova/nova-db.conf, and get all
> services that need db access to use it (ie: starting them with
This is going to be an issue for those services we run as a WSGI app. Looking at , I see
the app has a hardcoded list of config files to read (api-paste.ini and nova.conf), so we'd
need to modify it at the installer level.
Personally, I like the nova-db.conf way, since it looks like it reduces the amount of work
required for all-in-one installers to adapt, but that requires some code change. Would the
Nova team be happy with adding a nova-db.conf file to that list?
 - https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30
> If I understand well, these services would need access to db:
> - conductor
> - scheduler
> - novncproxy
> - serialproxy
> - spicehtml5proxy
> - api
> - api-metadata
> Is this list correct? Or is there some services that also don't need it?
> Thomas Goirand (zigo)
More information about the openstack-discuss