Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-10
15:50:59 dansmith gibi: okay
15:50:59 stephenfin so in one patch, we're catching that error and logging a warning instead (or falling back to the second call), and then in another we hard fail if DB configuration is present on a compute node?
15:51:05 stephenfin maybe I should just wait for the patches :)
15:51:15 dansmith stephenfin: yes
15:51:20 stephenfin lovely :-)
15:51:44 gibi :)
15:52:07 dansmith bauzas: you're asking if you can effectively only support 5.11 and not 5.0 in the bridge release that also supports 6.0?
15:52:35 bauzas dansmith: yeah, or whether we could wait until X
15:52:43 bauzas tbh, we would need to wait
15:53:21 sean-k-mooney bauzas: well 6.0 would be 5.11 right
15:53:22 bauzas but given the 5.1 version was for something like Queens, then I'm pretty sure that none of the clients would pass a legacy dict
15:53:22 dansmith bauzas: I think technically that works, but it's cheating of course... I guess I'd prefer to wait just to make it fully clean,
15:53:30 sean-k-mooney that what we normally do
15:53:33 dansmith but if it's something very hard to hold across the line, then maybe worth it
15:53:41 bauzas dansmith: okay, then I'll remove it
15:53:48 bauzas and we would remove those for X
15:54:06 sean-k-mooney dansmith: isnt that what we did for the 5.0 and 4.0 bumps
15:54:10 bauzas in case people look at my change later, maybe they wouldn't understand why we would remove this
15:54:27 bauzas sean-k-mooney: we still need to support 5.x in Wallaby
15:54:32 bauzas at least 5.11
15:54:43 dansmith bauzas: I'm not sure what you've decided.. are you going to leave the 5.0 stuff until X or strip it down to only be 5.11?
15:54:59 bauzas dansmith: tbh, I don't have a opinion
15:55:14 sean-k-mooney i think we stiped it for 5.0
15:55:16 bauzas dansmith: but after what you told, let's not delete the 5.0 support in my change
15:55:23 sean-k-mooney we could jsut check the patch
15:55:36 dansmith if you do it now, then you've got a lot of change, right? de-5.0ing the existing code, supporting 6.0, plus anything else we add between now and then, followed by a de-5.11ing in X
15:55:43 bauzas we could discuss about whether we would delete the <5.11 support before X
15:55:45 dansmith whereas if you leave it all, then you just de-5.x the whole thing at once
15:55:51 bauzas dansmith: yzah
15:55:55 bauzas anyway, nevermind
15:56:03 bauzas I'll return it
15:56:42 dansmith sean-k-mooney: I don't think I stripped the older 4.x support when we added 5.0 until after we dropped 4.x, but I could be wrong
15:56:46 sean-k-mooney this was the 5.0 bump https://github.com/openstack/nova/commit/a761e57368280b6d3e931831ecd393fd5787b3ef#diff-91f79786d7e3744c39926c88bbafe3b727630fa4eb48e845686d7f12f876d067
15:57:12 bauzas sean-k-mooney: dansmith: nevermind, again
15:57:19 sean-k-mooney so it loks like queens supported both
15:57:21 dansmith sean-k-mooney: that's the drop of 4.x not the bump
15:57:24 sean-k-mooney then we droped in rocky
15:57:26 dansmith right
15:57:33 bauzas for the main change, I'll just provide a new 6.0 RPC version but we will support 5.0
15:57:34 sean-k-mooney so i guess we do that
15:57:41 sean-k-mooney so drop in X
15:58:04 dansmith and you notice all the 4.x intermediate version parameter defaults are still there
15:58:05 bauzas and then we could do a remove in a later change that we could drop for 5.0 to 5.10, or just wait for X
15:58:16 dansmith bauzas: wait for X IMHO
15:58:49 bauzas yeah
15:58:54 bauzas it would be simplier
16:25:40 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/761452
17:21:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: Improve error handling during service level check https://review.opendev.org/762175
17:21:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent nova-compute start with DB credentials https://review.opendev.org/762176
17:21:57 gibi stephenfin, dansmith, sean-k-mooney: ^^ I followed what we discussed (or I hope so)
17:22:36 gibi I will leave for today now but tomorrow I can fix comments
17:22:39 gibi o/
17:25:01 stephenfin gibi: ta
18:03:13 sean-k-mooney gibi: yep that is what we discussed or at least what i understood we said we should do.
19:44:26 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199
19:45:51 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199
#openstack-nova - 2020-11-11
02:46:06 openstackgerrit chengsheng proposed openstack/nova master: Add hypervisor CPU feature check during live migration https://review.opendev.org/762272
06:29:57 openstackgerrit wu.shiming proposed openstack/python-novaclient master: Replace deprecated UPPER_CONSTRAINTS_FILE variable https://review.opendev.org/762292
08:46:05 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ussuri: [doc]: Fix glance image_metadata link https://review.opendev.org/761977
09:42:50 openstack Launchpad bug 1903824 in OpenStack Compute (nova) "Nova defaults [database]connection to local sqlite database while the config doc says it is defaulted to None" [Medium,Triaged] - Assigned to Balazs Gibizer (balazs-gibizer)
09:42:50 gibi dansmith, sean-k-mooney, stephenfin: look what a skeleton I found as a result of the yesterday's db credentials discussion https://bugs.launchpad.net/nova/+bug/1903824
09:56:44 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove [database]connection defaulting https://review.opendev.org/762319
09:56:44 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent nova-compute start with DB credentials https://review.opendev.org/762176
09:58:38 stephenfin oh, wow :-D
10:00:44 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent nova-compute start with DB credentials https://review.opendev.org/762176
10:51:23 owalsh stephenfin, gibi: re the nova db creds issues, is this likely to break a lot of config mgmt that assumes nova.conf can be common to all nova services?
10:53:37 gibi owalsh: if a config management tool did that and also used rpc pin 'auto' then it was already broken for a long time
10:54:08 owalsh gibi: I thought it would always fail now?
10:54:25 gibi yes, it will now fail even if rpc pin is not set to 'auto'
10:54:56 gibi also the documentation advise against setting [api_database]connection to nova-compute service https://docs.openstack.org/nova/latest/configuration/config.html#api_database.connection
10:55:15 gibi owalsh: what do you suggest? Do we make just a warning on master?
10:55:26 gibi wait a cycle, then move to hard fail?
10:55:27 owalsh gibi: I think we need /etc/nova/nova-compute.conf
10:55:37 owalsh we can not longer share /etc/nova/nova.conf
10:56:07 gibi I don't think nova suggested to share the nova.conf between services
10:56:27 gibi by default devstack generates nova-cpu.conf and that is the only conf passed to n-cpu
10:56:47 owalsh then nova-compute shouldn't default to /etc/nova/nova.conf
10:57:42 openstackgerrit chengsheng proposed openstack/nova master: Add hypervisor CPU feature check during live migration https://review.opendev.org/762330
10:58:12 owalsh I can fix this for tripleo and it's use of puppet-nova, but I would be concerned about other use cases of puppet-nova
10:58:38 gibi owalsh: do you refer to the doc in https://docs.openstack.org/nova/latest/cli/nova-compute.html#files that states nova.conf?
10:59:54 openstackgerrit YumengBao proposed openstack/nova-specs master: libvirt supports composing cyborg owned vGPU accelerator into domain XML https://review.opendev.org/750116
11:01:17 gibi owalsh: I did not find any other places that makes the suggestion that nova-compute needs nova.conf
11:01:51 owalsh gibi: how about the .debs/.rpms?
11:02:25 gibi I have no power over packagers, but sure we can ask them on the ML
11:03:02 gibi zigo: does the deb packages share nova.conf between the controller and the compute service?
11:03:15 owalsh gibi: for the rpms at least, the compute systemd runs /usr/bin/nova-compute
11:03:25 owalsh which will default to /etc/nova/nova.conf
11:05:16 gibi I don't find where nova implements that defaulting to /etc/nova/nova.conf
11:05:28 gibi stephenfin, dansmith: ^^ do you know where it is implemented?
11:11:46 gibi owalsh: I can reproduce that default behavior in devstack. So somewhere we says that nova-compute should read the nova.conf by default
11:13:49 owalsh gibi: ack, and puppet-nova (at least) is designed to generate one and only one nova.conf for all services by default
11:15:10 gibi that behavior is problematic regardless of what we are doing here. How puppet-nova is able to support multi cell deployments then? The different cell conductors needs to be pointed to different dbs
11:16:24 owalsh typically not on the same host
11:17:39 gibi but then if the nova-compute is on its own host then that nova-compute can have a nova.conf generated without db credentials
11:18:06 owalsh gibi: yes, but an all-in-one api+compute deployment will not work
11:18:11 gibi so I guess the only problematic scenario is when all in one
11:18:18 gibi yeah
11:19:31 owalsh snap :-) that's where the issue came up in CI but it shows how the conf logic in nova is far from ideal
11:19:33 gibi so with the current change we break all-in-one puppet-nova. But if we change what is the default config read by nova-compute we would still break puppet-nova as it only generates a singel config
11:20:04 gibi but also we break not only the all-in-one case but every csae

Earlier   Later