| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-17 | |||
| 18:08:09 | oomichi | alex_xu: need to update the remaining for conflicts | |
| 18:31:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Log compute node uuid when the record is created https://review.openstack.org/484447 | |
| 18:52:46 | mriedem | dansmith: sfinucan: nvm i think i know how that worked before - jsonutils.to_primitive() wouldn't error out, but wouldn't convert the NUMATopologyLimits either, so it would go through NovaObjectSerializer to do the serialize/deserialize work on the object | |
| 18:53:08 | mriedem | the new change in to_primitive to raise ValueError is what blew it all up because it would try to serialize before hitting the NovaObjectSerializer | |
| 18:53:22 | dansmith | sorry I missed the above ping, | |
| 18:53:25 | dansmith | but I assume I can ignore now | |
| 18:53:53 | mriedem | validation of my understanding, and feelings, is always appreciated, but yeah you can ignore probably | |
| 18:54:26 | dansmith | jsonutils.to_primitive used to fail with "recursion error" or something like that when it hit a non-serializeable object | |
| 18:56:15 | dansmith | mriedem: what change introduced this? | |
| 18:56:30 | dansmith | oh I see, in oslo | |
| 18:58:29 | mriedem | yeah that's what the oslo.serialization change was trying to prevent, the infinite recursion | |
| 18:58:37 | mriedem | by just failing fast | |
| 18:59:29 | dansmith | mriedem: so the thing I'm concerned about is: are we returning something that is only using jsonutils for serialization? | |
| 18:59:45 | dansmith | our object serializer doesn't go hunting in an iterable for any instance of an object to serialize | |
| 19:00:55 | dansmith | doesn't go arbitrarily deep, I mean | |
| 19:01:14 | mriedem | hmm yeah because that's what i was looking at with https://github.com/openstack/nova/blob/master/nova/objects/base.py#L244 | |
| 19:01:24 | mriedem | so it goes 1 level? | |
| 19:01:32 | mriedem | well, actually, | |
| 19:01:55 | mriedem | so this would be a like {'limits': {'numa_topology': object}} | |
| 19:01:59 | mriedem | so that should hit it ^ | |
| 19:02:24 | dansmith | where is this exactly? | |
| 19:02:29 | dansmith | is this in a returned value? | |
| 19:02:32 | mriedem | yeah | |
| 19:02:54 | mriedem | https://review.openstack.org/#/c/484439/2/nova/scheduler/manager.py@140 | |
| 19:03:33 | mriedem | creates a list of these dicts, and each dict will have a 'limits' key that maps to a dict, and that thing has the numa_topology_limits=NUMATopologyLimits object | |
| 19:03:34 | mriedem | map | |
| 19:05:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Optimize creating servers with tags https://review.openstack.org/484170 | |
| 19:05:18 | dansmith | I guess it will go pretty deep | |
| 19:05:24 | dansmith | had to re-read that a couple times | |
| 19:05:43 | mriedem | yeah so i think that's how it wasn't blowing up before | |
| 19:05:52 | mriedem | well, and was actually serializing the thing | |
| 19:06:07 | dansmith | yeah | |
| 19:06:10 | mriedem | the fact jsonutils.to_primitive ignored it was to our advantage | |
| 19:06:25 | dansmith | yeah | |
| 19:06:58 | mriedem | that change is also being reverted https://review.openstack.org/#/c/484396/ | |
| 19:07:18 | mriedem | b/c i pointed out that releasing that under a patch release versoin w/o any prior warning <2 weeks to FF is likely to break other projects | |
| 19:07:19 | dansmith | heh | |
| 19:07:25 | dansmith | yeah I guess so | |
| 19:07:53 | mriedem | we only had prior warning b/c the requirements changes gate on nova unit/functional tests | |
| 19:25:51 | mriedem | oomichi: i'm +2 again on https://review.openstack.org/#/c/479774/ after your comments | |
| 19:39:33 | Ctesias | hi. I'm digging around in nova trying to figure out why my nova_override.conf file isn't overriding nova defaults and I'm curious where `import nova.conf` and `CONF = nova.conf.CONF` are coming from because I don't see those being defined anywhere | |
| 19:41:28 | mriedem | Ctesias: for nova-compute the options are loaded up here https://github.com/openstack/nova/blob/master/nova/cmd/compute.py#L42 | |
| 19:41:45 | mriedem | similar pattern for the other service entry points | |
| 19:41:59 | mriedem | https://github.com/openstack/nova/blob/master/nova/config.py#L49 | |
| 19:43:15 | Ctesias | Thanks for the pointer. | |
| 19:43:31 | Ctesias | Is putting an override_nova.conf file in the config directory the right way to get overrides into the nova config? | |
| 19:44:10 | mriedem | i've never used nova_override.conf | |
| 19:44:17 | mriedem | so if it works, it's some magic i'm not aware of | |
| 19:45:14 | Ctesias | well... It doesn't work :( | |
| 19:45:27 | Ctesias | Any tips on how I would go about overriding defaults in nova.conf the right way? | |
| 19:45:56 | mriedem | can't you pass overrides on the --config-file cli option | |
| 19:46:02 | mriedem | i'm not sure though | |
| 19:46:38 | mriedem | there could be something in https://docs.openstack.org/oslo.config/latest/ | |
| 19:47:40 | sdague | Ctesias: can you explain what you are trying to do with overrides besides modifying the nova.conf directly? Maybe we're just not understanding the question | |
| 19:49:49 | Ctesias | I was under the impression modifying nova.conf directly was no bueno. But I'm trying to enable a barbican with Nova, so I need to set the api_class setting in config file under [keymgr] | |
| 19:50:21 | Ctesias | I created nova_override.conf in the same directory where nova.conf was and put [keymgr] and api_class = <the barbican manager> in it | |
| 19:50:24 | Ctesias | restarted nova | |
| 19:50:30 | Ctesias | but nova had the defaults when it came back | |
| 19:51:33 | mriedem | just modify nova.conf | |
| 19:52:00 | mriedem | nova.conf can be totally blank and it won't override any defaults - the defaults are all in code | |
| 19:52:08 | mriedem | so if you want to override any defaults, it happens in nova.conf | |
| 19:52:25 | mriedem | nova_override.conf is probably some package-specific trick | |
| 19:52:33 | Ctesias | .....Oh. | |
| 19:52:46 | Ctesias | Well awesome. Thanks for your help, really | |
| 19:52:50 | mriedem | yw | |
| 19:52:51 | Ctesias | I've been pulling my hair out for days | |
| 20:00:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Support tag instances when boot(4/4) https://review.openstack.org/469800 | |
| 20:00:55 | mriedem | Kevin_Zheng: ^ fixed up the functional test failures; it was pretty simple but not obvious until i injected some debug code and ran the tests, and then also had to tweak the tests a bit | |
| 20:03:30 | mriedem | sdague: can you take a gander at ^ ? it's pretty straight-forward and well tested | |
| 20:05:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Optimize creating servers with tags https://review.openstack.org/484170 | |
| 20:06:38 | sdague | mriedem: I'll add it to the morning list | |
| 20:06:56 | mriedem | thanks - alex_xu might get it overnight then, he was reviewing it before too | |
| 20:08:24 | oomichi | mriedem: thanks, +2 | |
| 20:10:10 | Ctesias | Hi again. I'm getting the same behavior with the changes directly in my nova.conf file. I've tried pointing at the directory with --config-dir and directly at the nova.conf file with --config-file with no change in behavior | |
| 20:10:20 | Ctesias | the api_class value is still the default | |
| 20:11:19 | mriedem | Ctesias: which service? | |
| 20:11:33 | Ctesias | nova service | |
| 20:11:45 | mriedem | which of the nova services, there are several | |
| 20:11:50 | mriedem | nova-osapi_compute? | |
| 20:11:57 | mriedem | nova-compute, etc | |
| 20:12:21 | Ctesias | nova-compute | |
| 20:13:59 | mriedem | when you restart nova-compute, do you have debug logging enabled so you can see it dump which config files are being used to and it will dump the options | |
| 20:16:46 | Ctesias | the file is pretty long, there something I can grep for to get the file it's using? | |
| 20:17:57 | mriedem | yeah | |
| 20:17:58 | mriedem | "command line args" | |
| 20:18:02 | mriedem | "config files" | |
| 20:18:07 | mriedem | like here http://logs.openstack.org/47/484447/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b2fbd0c/logs/screen-n-cpu.txt.gz#_Jul_17_18_47_11_345788 | |
| 20:18:22 | mriedem | and then it dumps the options it's using | |
| 20:19:05 | mriedem | Ctesias: you're using the wrong group | |
| 20:19:09 | mriedem | it's not [keymgr] | |
| 20:19:13 | mriedem | it's [key_manager] | |
| 20:19:21 | mriedem | http://logs.openstack.org/47/484447/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b2fbd0c/logs/screen-n-cpu.txt.gz#_Jul_17_18_47_11_670125 | |
| 20:19:28 | Ctesias | yeah, that was a typo earlier. I've got [key_manager] in the file | |
| 20:21:05 | Ctesias | If I put a breakpoint in nova/keymgr/conf_key_mgr.py I can go to the line after it grabs the nova configuration and see it's the same | |
| 20:21:10 | Ctesias | (Pdb) CONF['key_manager']['api_class'] 'nova.keymgr.conf_key_mgr.ConfKeyManager' | |
| 20:23:35 | mriedem | and the debug log output when you restart nova-compute shows the same when it dumps the options? | |
| 20:23:58 | Ctesias | yes | |
| 20:24:26 | Ctesias | 2017-07-17 16:20:13.483 DEBUG oslo_service.service [req-ece128f3-fb7c-4da3-af58-78c39fca910c None None] key_manager.api_class = nova.keymgr.conf_key_mgr.ConfKeyManager from (pid=14641) log_opt_values /opt/pf9/venv/lib/python2.7/site-packages/oslo_config/cfg.py:2626-07-17 16:20:13.485 DEBUG oslo_service.service [req-ece128f3-fb7c-4da3-af58-78c39fca910c None None] osapi_v21.project_id_regex = None from (pid=14641) | |
| 20:25:19 | mriedem | hmm, api_class comes from castellan | |
| 20:25:24 | mriedem | which version of that library do you have installed? | |