Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-10
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
11:42:38 owalsh gibi: ack but the services read those specific config files I assume
11:43:42 gibi owalsh: I think only if they are passed with --config-file to the binary
11:44:12 gibi I just quickly checked what files neutron-metadata-agent opens without any flag, and it seems it does the same default behavior as nova
11:44:38 gibi so it basically reads only neutron.conf by default
11:44:42 gibi http://paste.openstack.org/show/799911/
11:45:19 gibi so puppet-neutron not just generates those ini files but also adds them to the binary commandline
11:46:02 gibi so puppet-neutron does not realy on what file neutron binaries reads by default
11:47:56 owalsh gibi: I don't think puppet is adding the conf to the commandline, probably the .deb/.rpm service config
11:48:10 gibi could be
11:48:19 owalsh https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-metadata-agent.service#L8
11:49:03 gibi yep, so this rpm config seems to follow what devstack does
11:49:49 gibi compared that to https://github.com/rdo-packages/nova-distgit/blob/rpm-master/openstack-nova-compute.service
11:50:04 gibi I would say the neutron packaging config is better
11:50:56 gibi at least it is more structured and follow what devstack does
11:51:08 gibi so it is more closer what upstream CI tests
11:51:28 owalsh gibi: yea, but nova.conf has been around a lot longer :-)
11:52:17 gibi sure, I can imagine nova is historically used like that
12:26:18 zigo gibi: I don't unserstand your question. Do you mean, is it the same nova.conf on both roles? Yeah, it is.

Earlier   Later