<div dir="ltr">> So, I wanted to clarify something that came out of the IRC discussion,<br>> which is "do it like devstack". When we say that, or at least when *I*<br>
> said it, we meant "have different config files for each service so that<br>
> you can get the config elements appropriate for each service set<br><div>
> correctly." <br></div><div>I have one concern with the way we generate the default config, if we expect separated config files.</div><div>Currently in most of the distros we use oslo-config-generator to render the default conf file.</div><div>Since oslo-config-generator rendors all config options implemented in nova, we don't have any</div><div>good way to generate the sample config file for each service.</div><div>We didn't care which file we put the option since all services use the single file, but now we should always</div><div>refer to that documentation unless we implement generation of service-specific files or we write down</div><div>the services requiring that option in parameter description.</div><div># We have the same problem with nova-db.conf approach.<br></div><div><br></div><div>> Despite the fact that nobody *should* be setting these credentials in<br>> their config file, we know that at in least some circumstances, they<br>
> are. TripleO is setting them (always I think?) because puppet-nova does<br>
> that. ...<br></div><div>The issue with TripleO was fixed by the change in puppet-nova[1], and nova.conf for</div><div>nova-compute service no longer includes database credentials.<br></div><div>We can backport the fix is needed, as per discussion with owalsh on the previous mails.</div><div> [1] <a href="https://review.opendev.org/#/c/755689/">https://review.opendev.org/#/c/755689/</a></div><div><br></div><div>But from puppet-nova's perspective the sandalone deployment or ironic deployment(*1)</div><div>still needs some fix to address the separate config files, because all processes run on host,</div><div>not on container, and refer to the same default conf file, nova.conf.<br></div><div>Since puppet-nova follows the way how distro packaging provides the default config files,</div><div>we need to fix current implementation in puppet-nova after each distro packages provide<br></div><div>the updated version with new config file structure.</div><div><br></div><div>(*1)</div><div>In usual deployment with ironic, we have nova-compute running on the controller nodes,</div><div>where nova-api is also running, IIUC.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 4:27 AM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> 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">> There was a long discussion on #openstack-nova today[3] around this<br>
> topic. So you can find more detailed reasoning there[3].<br>
<br>
I just had a long voice chat with Ollie about this, trying to understand<br>
some of the challenges that still exist with some of the things we've<br>
discussed and the proposed forward steps.<br>
<br>
There are lots of things to clarify, I think, and we could honestly<br>
probably use a wider voice chat among the people that need to work on<br>
this. However, I'll try here.<br>
<br>
First off, I want to address the "do it like devstack" recommendation,<br>
and the subsequent suggestion of standardizing on something like a<br>
"nova-db.conf" file arrangement to keep the db credentials in one<br>
place. As Ollie has pointed out, devstack doesn't support all the<br>
various deployment arrangements (such as "one metadata api per cell")<br>
and thus doesn't have a prescription for how to arrange the config files<br>
in those scenarios. Specifically, an all-in-one deployment that includes<br>
multiple API services with different configs would currently have to hack<br>
around the hardcoded nova.conf file with the environment variable that<br>
allows them to specify a directory other than /etc/nova.conf. Devstack<br>
doesn't have to do this because it doesn't support that arrangement of<br>
services, but if it did, it would have to.<br>
<br>
So, I wanted to clarify something that came out of the IRC discussion,<br>
which is "do it like devstack". When we say that, or at least when *I*<br>
said it, we meant "have different config files for each service so that<br>
you can get the config elements appropriate for each service set<br>
correctly." That doesn't mean "nova-compute should point to<br>
/etc/nova/nova-cpu.conf because that's what devstack does". Especially<br>
in a containerized setup, I would expect everything to use<br>
/etc/nova/nova.conf, since those are namespaced per-service because of<br>
the containerization. Further, just because devstack doesn't run a<br>
metadata per cell (or any other such optional arrangement), obviously<br>
that doesn't mean you can't.<br>
<br>
That leads me to the first action item I think we need:<br>
<br>
ACTION 1: Make the wsgi app able to use something other than nova.conf<br>
<br>
All of our other services support a --config-file flag, and I don't see<br>
why we wouldn't allow this if it's necessary for deployments. In the<br>
pure API arrangement, it shouldn't really be necessary to change this,<br>
but clearly you may need to have multiple API workers with different<br>
configs, as is the case with metadata-per-cell, or even potentially some<br>
admin-focused private API endpoint. If it makes it easier for deployment<br>
tools to start the API workers with a specific config file, we should<br>
let them do that. You can already work around that hard-coded filename<br>
by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but we<br>
shouldn't require them to create directories just to have separate<br>
configs.<br>
<br>
The next item is related:<br>
<br>
ACTION 2: We need to document a minimal viable config for each service<br>
<br>
Ollie points out that, obviously, handing the deployer a config<br>
reference with 1.21 bajillion config options does not clearly indicate<br>
which services need which thing, and especially, which things are<br>
_not_allowed_ to be set for a service (such as db credentials on the<br>
compute). We can't feasibly audit every config option we have, but it<br>
would be very helpful to have a reference that shows what a completely<br>
minimal configuration for each service looks like. We could do that by<br>
tagging services per config options (which I suggested earlier, and<br>
would still be good) but I think maybe a standalone document would be<br>
easier for people to follow.<br>
<br>
Now, on to the question about the hard-fail patch for compute:<br>
<br>
  <a href="https://review.opendev.org/#/c/762176/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/762176/</a><br>
<br>
The Nova devs have wanted people to _not_ have db credentials in the<br>
config file that nova-compute can see for a "Very Long Time." We have<br>
even made some assumptions in the code that rely on these credentials<br>
being not set on the compute, which is at least partially why we're<br>
having this conversation (again) now.<br>
<br>
Despite the fact that nobody *should* be setting these credentials in<br>
their config file, we know that at in least some circumstances, they<br>
are. TripleO is setting them (always I think?) because puppet-nova does<br>
that. OSA has said that they're setting them somewhat incidentally when<br>
they do all-in-one deployments. The latter is unlikely to affect any<br>
real deployments, but the former definitely _will_, and anyone else that<br>
isn't present in this discussion may be including credentials<br>
unnecessarily, which we will break when we merge that patch. Thus, I<br>
think that, even though it feels long overdue for devs, the most prudent<br>
and cautious approach will be to:<br>
<br>
ACTION 3: Not merge that hard fail until X<br>
<br>
We have the warning, we have the reno. We expect that the deployment<br>
tools will be working to eliminate the credentials for the compute<br>
config, but merging that will make it an emergency for them. We've<br>
waited years at this point, we can wait one more cycle for safety. As<br>
Ollie pointed out, we've not been super clear about messaging this,<br>
despite it being a well-worn assumption amongst the developers for a<br>
long time.<br>
<br>
To aid in smoking out any of the jobs or configs that deployment tools<br>
may still have which will break when we merge that patch, we should also<br>
consider:<br>
<br>
ACTION 4: A workaround flag to opt-in to the strict checking<br>
<br>
Basically, this would be a one or two-cycle workaround, which when<br>
enabled, would opt-in to the (above) behavior of causing compute to fail<br>
on startup if db credentials are present. This would allow the<br>
deployment tool maintainers, as well as people responsible for CI jobs<br>
to smoke test the new behavior early, before we merge it and cause an<br>
emergency for them. We can set this as on by default in our devstack<br>
jobs to signal that it is good with the new behavior, and also encourage<br>
the other deployment projects to set it as well once they're generating<br>
clean configs for their nova-computes. Once we merge the patch to<br>
actually fail all the time, we can remove this workaround config,<br>
according to the original intent of the workarounds group, that those<br>
flags are short-lived.<br>
<br>
We could do this by altering gibi's patch to only fail if the workaround<br>
is enabled, and then follow up in X by removing the workaround check.<br>
<br>
So, I know that was a lot of words, but I think if we can agree to the<br>
above four items, we'll have a path forward that doesn't overly burden<br>
any one specific group while still allowing us to chart a path to<br>
getting where we want to be.<br>
<br>
I think we need acks from a bunch of groups, probably at least:<br>
<br>
- Nova (gibi, stephenfin)<br>
- TripleO (owalsh)<br>
- Debian (zigo)<br>
- Kolla (yoctozepto)<br>
- OSA (noonedeadpunk)<br>
- rdo-ci (jpena)<br>
- puppet-nova (tkajinam)<br>
<br>
Are people okay with these action items?<br>
<br>
--Dan<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>----------</div><div>Takashi Kajinami<br></div><div>Senior Software Maintenance Engineer<span style="font-family:arial,helvetica,sans-serif"></span><br><div style="outline:currentcolor none medium"><div dir="ltr">Customer Experience and Engagement<br>Red Hat</div><div>e-mail: <a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a></div><div dir="ltr"><br></div></div></div></div></div></div></div>