Open Stack

On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer <balazs.gibizer at est.tech>
wrote:

>
>
> On Thu, Nov 12, 2020 at 06:09, Javier Pena <jpena at 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 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 [2] 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 [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
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_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?
> >>
> >>  Cheers,
> >>
> >>  Thomas Goirand (zigo)
> >>
> >>
> >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/fe23dfd9/attachment.html>