Open Stack

On Fri 13 Nov 2020, 22:06 Sean Mooney, <smooney at redhat.com> wrote:

> On Fri, 2020-11-13 at 19:59 +0000, Oliver Walsh wrote:
> > On Fri 13 Nov 2020, 16:18 Oliver Walsh, <owalsh at redhat.com> wrote:
> >
> > >
> > >
> > > 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
> > >
> >
> > But hang on a second... metadata-api is a wsgi app, which hardcodes
> > 'nova.conf', so how can this work in devstack?
> 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_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/71f2e471/attachment-0001.html>