when someone manually installs the RDO RPMs and use a single nova.conf for computes and controllers and has the database connections set. IIRC the idea was to package a second nova.conf for the computes and modify the systemd unit file for nova-compute to use the new one.

But we need to make sure we don't introduce any conflict with ooo, which I think we don't as the container specifies which config to use.

There is [1], the upstream discussion on this.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018663.html

+++ This bug was initially created as a clone of Bug #1896995 +++

Currently all nova database sections are configured for all nova services (inherited from nova-base). I assume this an historical relic from the days when nova compute accessed the db directly.

This is long deprecated and removed. Code has already merged in nova that assumes the api db is not configured on computes. Devstack [1] and kolla-ansible[2] have already hit this.

From investigation by the nova devs it appears that tripleo was just fortunate not to hit the same issue. Setting upgrade level 'auto' would have triggered it.

[1] https://bugs.launchpad.net/devstack/+bug/1812398
[2] https://bugs.launchpad.net/kolla-ansible/+bug/1829705

--- Additional comment from Martin Schuppert on 2020-11-12 10:34:21 EST ---

Work on tripleo is tracked in 1851239. From our meeting this BZ is meant to track the work in openstack-nova rpms.

--- Additional comment from RHEL Program Management on 2021-01-05 11:35:44 EST ---

This bugzilla has been removed from the release since it  does not have an acked release flag. For details, see https://mojo.redhat.com/docs/DOC-1144661#jive_content_id_OSP_Release_Planning.'

--- Additional comment from RHEL Program Management on 2021-01-05 11:36:02 EST ---

This bugzilla has been removed from the release since it  does not have an acked release flag. For details, see https://mojo.redhat.com/docs/DOC-1144661#jive_content_id_OSP_Release_Planning.'