| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-10 | |||
| 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 | |
| 11:20:06 | gibi | case | |
| 11:20:14 | owalsh | yea, would need a deprecation cycle to alter this | |
| 11:20:33 | gibi | I need second opinion from dansmith about all these | |
| 11:21:57 | gibi | I do feel that nova should not bend over to support all-in-one cases, and the normal deployment cases migth depend on the fact that nova-compute reads the nova.conf by default | |
| 11:22:24 | owalsh | ack. FWIW I can fix the tripleo use case but I'm nervous about more general usage of nova and/or puppet-nova (e.g manual install with rpms/debs or traditional puppet usage) | |
| 11:23:30 | owalsh | and seem to have a contradiction in nova now where it explicitly forbids sharing nova.conf but defaults to sharing nova.conf | |
| 11:33:00 | gibi | I found where we default nova.conf. It is in oslo.config https://github.com/openstack/oslo.config/blob/68cefad313bd03522e99b3de95f1786ebea45d4b/oslo_config/cfg.py#L281 | |
| 11:33:44 | gibi | nova defines no default config, oslo assigns default files based on the project name and binary name | |
| 11:36:59 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/756552 | |
| 11:36:59 | gibi | owalsh: so I would not be suprised that other openstack modules have the same behavior | |
| 11:39:14 | gibi | owalsh: just out of curiosity how many config files puppet generate for neutron? In devstack I see that neutron promotes sharing the neutron.conf but customize it with extra service specific conf files as well | |
| 11:40:13 | owalsh | gibi: no idea, only really know puppet-nova... | |
| 11:40:41 | gibi | OK, no worries, I was just curious what is the pattern in puppet | |
| 11:41:06 | owalsh | gibi: *_config from https://github.com/openstack/puppet-neutron/tree/master/lib/puppet/provider | |
| 11:42:00 | gibi | owalsh: based on that puppet-neutron follows what devstack does | |
| 11:42:12 | gibi | and generates one neutron.conf and a list of service specific .ini files as config | |