On Fri 13 Nov 2020, 22:06 Sean Mooney, <smooney@redhat.com> wrote:
On Fri 13 Nov 2020, 16:18 Oliver Walsh, <owalsh@redhat.com> wrote:
On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
On Thu, Nov 12, 2020 at 06:09, Javier Pena <jpena@redhat.com> wrote:
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[1] nova-compute > service fails if you configure API DB credentials and set upgrade_level > config to 'auto'. > > Now we are proposing a patch[2] 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
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 [2] during Wallaby but we are OK to > delay the patch until Wallaby Milestone 2 so that the
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 [2] to be merged. > > There was a long discussion on #openstack-nova today[3] around this > topic. So you can find more detailed reasoning there[3]. > > 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 --config-file=/etc/nova/nova-db.conf)?
Hi,
This is going to be an issue for those services we run as a WSGI app. Looking at [1], 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?
Devstack solves the all-in-one case by using these config files:
* nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and nova-metadata-api
* nova.conf for the nova-scheduler and the top level nova-conductor
(super conductor) * nova-cell<cell-id>.conf for the cell level nova-conductor and the proxy services, e.g. nova-novncproxy
* nova-cpu.conf for the nova-compute service
IIUC for nova-metadata-api "it depends": local_metadata_per_cell=True it needs nova-cell<cell-id>.conf
But hang on a second... metadata-api is a wsgi app, which hardcodes 'nova.conf', so how can this work in devstack?
On Fri, 2020-11-13 at 19:59 +0000, Oliver Walsh wrote: packaging, packagers the nova.conf has the db creds in devstack. nova-compute is run with its own config and does not use nova.conf at all
Yes, if its a global metadata api, but for a cell local metadata api it needs to use nova-cell<cell-id>.conf
we did not really expect nova.conf to be passed as a paramter to the comptue service.
local_metadata_per_cell=False it needs nova.conf
Cheers, Ollie
The nova team suggest to use a similar strategy to separate files. So
at the moment we are not planning to change what config files the wsgi
apps will read.
Cheers, gibi
Regards, Javier
[1] -
https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi...
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?
Cheers,
Thomas Goirand (zigo)