<div>Hi,</div><div> </div><div>Well, while OSA really place DB credentials into nova.conf only when needed, this patch will still break our all-in-one setup. I have nothing against approach of</div><div>the separating config files, but I'm sure this needs to be really well documented. Also would be great to have list of options that are required for nova-compute</div><div>to work. As then it makes sense to do nova-compute.conf as minimal as possible and exclude all scheduler and placement bits from it as well (and libvirt</div><div>from scheduler/api part of the conf).</div><div> </div><div> </div><div>11.11.2020, 23:12, "Sean Mooney" <smooney@redhat.com>:</div><blockquote><p>On Wed, 2020-11-11 at 21:08 +0100, Thomas Goirand wrote:</p><blockquote> 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 database<br /> > via the conductor service. Also, the nova configuration guide 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 that<br /> > service runs close to the hypervisor. Since Rocky[1] nova-compute<br /> > service fails if you configure API DB credentials and set upgrade_level<br /> > config to 'auto'.<br /> ><br /> > Now we are proposing a patch[2] that makes nova-compute fail at startup<br /> > if the [database]connection or the [api_database]connection is<br /> > configured. We know that this breaks at least the rpm packaging, debian<br /> > packaging, and puppet-nova. The problem there is that in an 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 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 an<br /> > all-in-on setup.<br /> ><br /> > The nova team would like to merge [2] during Wallaby but we are OK to<br /> > delay the patch until Wallaby Milestone 2 so that the packagers and<br /> > deployment tools can catch up. Please let us know if you are impacted<br /> > and provide a way to track when you are ready with the modification that<br /> > allows [2] to be merged.<br /> ><br /> > 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 /> > Cheers,<br /> > gibi<br /> <br /> IMO, that's ok if, and only if, we all agree on how to implement it.</blockquote><p>well not to be too blunt but im not sure we resonably can chose not to implement this.<br /><br />i has been raised by customer that have don a security audit in the past as a hardening issue<br />that the db cred which are unused are present on the compute nodes.<br /><br />all agreeing to do it the same way woudl be a good thing but at the end of the day we should do this<br />this cycle. we also shoudl come up with some upstream recomendation in the install docs on the best partice for this<br />hopefully we can get agreement but if a specific config managment tool chosses to go a different way i dont think they<br />should be force to chagne.<br /><br />for example kolla already dose the right thing and has for several releases.<br />i dont think they shoudl need to change there approch.<br /><br />the have a singel nova.conf per container but a different one for each container<br /><a href="https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/templates/nova.conf.j2#L136-L151" rel="noopener noreferrer">https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/templates/nova.conf.j2#L136-L151</a><br />the nova.conf for the compute contaienr dose not contian the db info which is the correct approch.<br /><br />openstack ansible also do the same thing<br /><a href="https://github.com/openstack/openstack-ansible-os_nova/blob/master/templates/nova.conf.j2#L183-L199" rel="noopener noreferrer">https://github.com/openstack/openstack-ansible-os_nova/blob/master/templates/nova.conf.j2#L183-L199</a><br /><br />ooo will do the same thing<br />once <a href="https://review.opendev.org/#/c/718552/" rel="noopener noreferrer">https://review.opendev.org/#/c/718552/</a> is done more or less.<br /><br />so form a config managment point of view the pattern is to generate a configile with only the info tha tis needed.<br /><br />form a packager point of view hte only way to mimic that is to use multiple files with descreeet chunks<br />or to not install any config by default nad require operators to copy thet samples.<br /><br />the install guides dont expclitly call this out<br /><a href="https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html#install-and-configure-components" rel="noopener noreferrer">https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html#install-and-configure-components</a><br /><a href="https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html#install-and-configure-components" rel="noopener noreferrer">https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html#install-and-configure-components</a><br /><br />but the compute node one does not tell you to add the db config either.<br /><br />i do thikn we shoudl update the comptue node install docs to use a different file however instad of nova.conf.<br /> </p><blockquote> Best would be if we (all downstream distro + config management) 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)?</blockquote><p>we might want two db files so nova-cell-db and nova-api-db really</p><blockquote> <br /> If I understand well, these services would need access to db:<br /> - conductor</blockquote><p>the super conductor need the cell db and the api db<br /><br />form talking to dan the instance affinity/antiaffintiy late check would reuire<br />the cell db to unfortually need api db access too.<br /><br /> </p><blockquote> - scheduler</blockquote><p>the scudler need db acess although im not sure if it needs both.<br /> </p><blockquote> - novncproxy<br /> - serialproxy<br /> - spicehtml5proxy</blockquote><p><br />so im not sure if these 3 do.<br />they might for some kind fo token storage although i did not think they really<br />should need db acess, maybe to get the instance host, it would be nice if these could be restrcted<br />to just use the api db but they might need both.<br /><br /> there is a propsal too support passwords with consoles.<br /><a href="https://review.opendev.org/#/c/759828/" rel="noopener noreferrer">https://review.opendev.org/#/c/759828/</a><br />i have not check but i assume that will require tehm to have db access if they do not already.<br />although i think the password enforcement might be via the hypervisor e.g. libvirt so they may not<br />need db acess for that. we should determin that.<br /><br /> </p><blockquote> - api<br /> - api-metadata</blockquote><p>the api and metadata api both need db acess yes.<br />i think we need both the api db and cell db acess in both cases.</p><blockquote> <br /> Is this list correct? Or is there some services that also don't need it?</blockquote><p>the only other nova service is the compute agent and it does not need db acess.<br /><br />im not sure if there is utility in</p><blockquote> <br /> Cheers,<br /> <br /> Thomas Goirand (zigo)<br /> </blockquote><p><br /><br /> </p></blockquote><div> </div><div> </div><div>-- <br />Kind Regards,</div><div>Dmitriy Rabotyagov</div><div> </div>