<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri 13 Nov 2020, 16:18 Oliver Walsh, <<a href="mailto:owalsh@redhat.com" target="_blank" rel="noreferrer">owalsh@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer <balazs.gibizer@est.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Thu, Nov 12, 2020 at 06:09, Javier Pena <<a href="mailto:jpena@redhat.com" rel="noreferrer noreferrer" target="_blank">jpena@redhat.com</a>> wrote:<br>
>>  On 11/11/20 5:35 PM, Balázs Gibizer wrote:<br>
>>  > Dear packagers and deployment engine developers,<br>
>>  ><br>
>>  > Since Icehouse nova-compute service does not need any database<br>
>>  > configuration as it uses the message bus to access data in the <br>
>> database<br>
>>  > via the conductor service. Also, the nova configuration guide <br>
>> states<br>
>>  > that the nova-compute service should not have the<br>
>>  > [api_database]connection config set. Having any DB credentials<br>
>>  > configured for the nova-compute is a security risk as well since <br>
>> that<br>
>>  > service runs close to the hypervisor. Since Rocky[1] nova-compute<br>
>>  > service fails if you configure API DB credentials and set <br>
>> upgrade_level<br>
>>  > config to 'auto'.<br>
>>  ><br>
>>  > Now we are proposing a patch[2] that makes nova-compute fail at <br>
>> startup<br>
>>  > if the [database]connection or the [api_database]connection is<br>
>>  > configured. We know that this breaks at least the rpm packaging, <br>
>> debian<br>
>>  > packaging, and puppet-nova. The problem there is that in an <br>
>> all-in-on<br>
>>  > deployment scenario the nova.conf file generated by these tools is<br>
>>  > shared between all the nova services and therefore nova-compute <br>
>> sees DB<br>
>>  > credentials. As a counter-example, devstack generates a separate<br>
>>  > nova-cpu.conf and passes that to the nova-compute service even in <br>
>> an<br>
>>  > all-in-on setup.<br>
>>  ><br>
>>  > The nova team would like to merge [2] during Wallaby but we are <br>
>> OK to<br>
>>  > delay the patch until Wallaby Milestone 2 so that the packagers <br>
>> and<br>
>>  > deployment tools can catch up. Please let us know if you are <br>
>> impacted<br>
>>  > and provide a way to track when you are ready with the <br>
>> modification that<br>
>>  > allows [2] to be merged.<br>
>>  ><br>
>>  > There was a long discussion on #openstack-nova today[3] around <br>
>> this<br>
>>  > topic. So you can find more detailed reasoning there[3].<br>
>>  ><br>
>>  > Cheers,<br>
>>  > gibi<br>
>> <br>
>>  IMO, that's ok if, and only if, we all agree on how to implement it.<br>
>>  Best would be if we (all downstream distro + config management) <br>
>> agree on<br>
>>  how to implement this.<br>
>> <br>
>>  How about, we all implement a /etc/nova/nova-db.conf, and get all<br>
>>  services that need db access to use it (ie: starting them with<br>
>>  --config-file=/etc/nova/nova-db.conf)?<br>
>> <br>
> <br>
> Hi,<br>
> <br>
> This is going to be an issue for those services we run as a WSGI app. <br>
> Looking at [1], I see<br>
> the app has a hardcoded list of config files to read (api-paste.ini <br>
> and nova.conf), so we'd<br>
> need to modify it at the installer level.<br>
> <br>
> Personally, I like the nova-db.conf way, since it looks like it <br>
> reduces the amount of work<br>
> required for all-in-one installers to adapt, but that requires some <br>
> code change. Would the<br>
> Nova team be happy with adding a nova-db.conf file to that list?<br>
<br>
Devstack solves the all-in-one case by using these config files:<br>
<br>
* nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and <br>
nova-metadata-api </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* nova.conf for the nova-scheduler and the top level nova-conductor <br>
(super conductor)<br>
* nova-cell<cell-id>.conf for the cell level nova-conductor and the <br>
proxy services, e.g. nova-novncproxy </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* nova-cpu.conf for the nova-compute service<br></blockquote><div><br></div><div><div>IIUC for nova-metadata-api "it depends":</div><div>local_metadata_per_cell=True it needs nova-cell<cell-id>.conf</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">But hang on a second... metadata-api is a wsgi app, which hardcodes 'nova.conf', so how can this work in devstack?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div>local_metadata_per_cell=False it needs nova.conf</div><div><br></div><div>Cheers,</div><div>Ollie</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The nova team suggest to use a similar strategy to separate files. So  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
at the moment we are not planning to change what config files the wsgi <br>
apps will read.<br>
<br>
Cheers,<br>
gibi<br>
<br>
<br>
> <br>
> Regards,<br>
> Javier<br>
> <br>
> <br>
> [1] - <br>
> <a href="https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30" rel="noreferrer noreferrer noreferrer" target="_blank">https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30</a><br>
> <br>
>>  If I understand well, these services would need access to db:<br>
>>  - conductor<br>
>>  - scheduler<br>
>>  - novncproxy<br>
>>  - serialproxy<br>
>>  - spicehtml5proxy<br>
>>  - api<br>
>>  - api-metadata<br>
>> <br>
>>  Is this list correct? Or is there some services that also don't <br>
>> need it?<br>
>> <br>
>>  Cheers,<br>
>> <br>
>>  Thomas Goirand (zigo)<br>
>> <br>
>> <br>
> <br>
> <br>
<br>
<br>
<br>
</blockquote></div></div>
</blockquote></div></div></div>