| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-24 | |||
| 14:09:47 | mdbooth | bauzas: artom gets all your beer :) | |
| 14:10:50 | kashyap | artom: Ah, nice one. Yep, that's it | |
| 14:11:32 | bauzas | mdbooth: FWIW I just marked the bug we discussed as incomplete since I'd like the reporter to test the last ocata point release | |
| 14:11:42 | bauzas | as it includes artom's patch | |
| 14:11:53 | mdbooth | +1 | |
| 14:14:38 | bauzas | dansmith: mmm, we have lots of docs mentioning it's worth doing SIGHUPs for upgrades or mutable config but I don't see how nova-compute service is hooking up this signal :) | |
| 14:14:56 | bauzas | dansmith: since it's not inheriting from oslo.service AFAICT | |
| 14:15:09 | bauzas | and we don't have any signal handling in that code | |
| 14:15:50 | dansmith | bauzas: oh, this reminds me, someone recently asked me about a doc they found that says they could change the log level at runtime | |
| 14:15:54 | dansmith | by SIGHUP | |
| 14:16:11 | dansmith | it clearly was not working and I told them I expected that was oslo documentation, but never circled back | |
| 14:17:03 | bauzas | dansmith: https://bugs.launchpad.net/nova/+bug/1705680 led me investigating and honesly I don't see how the magic can happen | |
| 14:17:04 | openstack | Launchpad bug 1705680 in OpenStack Compute (nova) "nova compute does nothing on receiving sighup signal" [Undecided,New] | |
| 14:17:15 | bauzas | if we were inheriting from oslo.service manager, then OK | |
| 14:17:19 | bauzas | but we're not | |
| 14:17:44 | dansmith | we do process sighup for rpc version pins | |
| 14:18:12 | dansmith | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L539 | |
| 14:18:35 | bauzas | dansmith: I saw the hook | |
| 14:18:50 | bauzas | dansmith: but I don't see how we define that hook to be called on a sighup signal | |
| 14:19:03 | dansmith | I think we do get it from oslo.service | |
| 14:19:07 | dansmith | but it's buried pretty deep | |
| 14:19:23 | bauzas | dansmith: that was my assumption | |
| 14:19:24 | bauzas | but | |
| 14:19:29 | bauzas | we don't inherit from it | |
| 14:19:34 | dansmith | we do | |
| 14:19:46 | dansmith | bauzas: https://github.com/openstack/nova/blob/master/nova/service.py#L98-L98 | |
| 14:19:52 | dansmith | bauzas: service is oslo.service there | |
| 14:20:08 | dansmith | L27 | |
| 14:20:11 | bauzas | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L482 | |
| 14:20:22 | bauzas | manager is nova.manager, right? | |
| 14:20:37 | dansmith | yes, but the service hooks Service.reset() to Manager.reset() | |
| 14:20:47 | dansmith | https://github.com/openstack/nova/blob/master/nova/service.py#L289-L289 | |
| 14:21:00 | bauzas | but https://github.com/openstack/nova/blob/master/nova/manager.py#L91 | |
| 14:21:13 | mriedem | dansmith: the mutable config stuff is in oslo.config docs | |
| 14:21:14 | bauzas | dansmith: ooooh, it's fucking cryptic | |
| 14:21:25 | mriedem | https://docs.openstack.org/oslo.config/latest/reference/mutable.html | |
| 14:21:34 | dansmith | bauzas: not really, managers and services have always had this relationship | |
| 14:21:55 | bauzas | I see | |
| 14:21:59 | dansmith | mriedem: oh right and I think we're writing into our default nova config that log level is mutable or something | |
| 14:22:04 | dansmith | because of that | |
| 14:22:56 | mriedem | i thought it was only 'debug' | |
| 14:23:19 | mriedem | https://review.openstack.org/#/c/280851 | |
| 14:23:39 | mriedem | https://review.openstack.org/#/c/254821/ | |
| 14:23:52 | bauzas | mriedem: I was just looking at the mutable-config series | |
| 14:23:53 | dansmith | mriedem: okay I never saw this, but it completely wasn't working | |
| 14:23:55 | mriedem | so default_log_levels config wouldn't use that | |
| 14:24:17 | dansmith | I think it was debug= they were toggling, but maybe not | |
| 14:24:51 | mriedem | https://docs.openstack.org/nova/latest/sample_config.html | |
| 14:24:51 | mriedem | we only have 4 | |
| 14:24:58 | mriedem | if you search for "Note: This option can be changed without restarting." | |
| 14:25:28 | dansmith | wonder if we're supposed to be hooking our sighup handler to oslo.log somehow? | |
| 14:25:37 | bauzas | mriedem: correct, the mutable-config series was mostly still in progress when lxsli left | |
| 14:25:38 | dansmith | unless it registers its own signal handler quietly | |
| 14:26:41 | bauzas | the point with https://bugs.launchpad.net/nova/+bug/1705680 is that I suspect the sighup to be caught but just the fact that we only reload a very few flags made the reporter thinking it wasn't working | |
| 14:26:42 | openstack | Launchpad bug 1705680 in OpenStack Compute (nova) "nova compute does nothing on receiving sighup signal" [Undecided,New] | |
| 14:26:59 | bauzas | either way, I can call out for details | |
| 14:31:11 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 14:55:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Adopt new pypowervm power_off APIs https://review.openstack.org/476945 | |
| 14:56:05 | openstackgerrit | Sean Dague proposed openstack/nova master: Increase cpu time for image conversion https://review.openstack.org/486642 | |
| 14:59:16 | s-dean | can somebody please confirm that the cells table in nova db is meant to be empty, I have been trying to setup the cells database and every time i run su -s /bin/sh -c "nova-manage db sync" nova , I get the following output ERROR: could not access cell mapping database - has api db been created?, I have been at this for 5 days and same error everytime i reinstall | |
| 14:59:28 | jangutter | sean-k-mooney: are you inline? | |
| 14:59:35 | jangutter | s/inline/online/? | |
| 15:02:48 | sean-k-mooney | yes though i have to drop for meeting in an hour | |
| 15:03:14 | sean-k-mooney | jangutter: ^ | |
| 15:03:52 | jangutter | sean-k-mooney: I split off https://review.openstack.org/#/c/486426/ but I'm not sure I wrote the test right. | |
| 15:05:49 | sean-k-mooney | jangutter: well that is partly a technically question and partly a political one. you added _set_config_VIFHostDevice | |
| 15:06:53 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from 'ip' commands to pyroute2 https://review.openstack.org/484386 | |
| 15:08:04 | mriedem | s-dean: yes the cells table is for cells v1 only | |
| 15:08:06 | jangutter | sean-k-mooney: yep, and used "unplugin" rather than "plugin" -> other VIF tests that don't go out via an os-vif plugin seem to use that, rather than "plugin" | |
| 15:08:07 | sean-k-mooney | jangutter: technically in test_vif.py you should only assert that the designer was called. and then in https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/test_designer.py you should assert that correct xml is generated when you pass in the os_vif_hostdevice | |
| 15:08:25 | mriedem | s-dean: you have a nova_api db yes? | |
| 15:08:33 | mriedem | s-dean: did you run nova-manage api_db sync ? | |
| 15:09:08 | mriedem | s-dean: also https://docs.openstack.org/nova/latest/cells.html and https://docs.openstack.org/ocata/install-guide-ubuntu/nova.html for docs | |
| 15:09:22 | sean-k-mooney | jangutter: but politcally nova has not done it this way else where in the file so you should follow the files convention of have test_vif.py also test desighern fuctionality though really this should be change across the board in that file in a seperate patch | |
| 15:09:37 | jangutter | sean-k-mooney: ah, that makes it a lot finer-grained. | |
| 15:10:57 | sean-k-mooney | jangutter: yes unfutrnetlly that is not how the other unitest have been written so it better to follow the convention in the file though we should proably file a bug to make it more granular | |
| 15:11:35 | sean-k-mooney | jangutter: i think the current patch is fine given the convention that is inplace | |
| 15:11:43 | mriedem | s-dean: it could also mean that the nova.conf that you're running nova-manag db sync against doesn't have the [api_database]connection option set? | |
| 15:12:20 | s-dean | yes I have nova_api database, I have run the commands in order as specified in the documentation, However ERROR: could not access cell mapping database - has api db been created? | |
| 15:12:29 | s-dean | keeps appearing | |
| 15:12:45 | mriedem | s-dean: the command is looking for entries in the cell_mappings table in the nova_api db | |
| 15:12:59 | s-dean | they exist | |
| 15:13:07 | jangutter | sean-k-mooney: thanks, I and that clears up the other questions I also had. I had wondered why there seemed to be two sets of tests in test_vif.py | |
| 15:13:11 | mriedem | or whatever you called it, but it would be defined by the [api_database]connection url in nova.conf | |
| 15:13:13 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(2/2) https://review.openstack.org/408964 | |
| 15:13:26 | mriedem | s-dean: how do the cell_mappings entries exist if you don't have a nova_api db? | |
| 15:13:33 | mriedem | oh you said you have it | |
| 15:13:34 | stvnoyes | mriedem good morning Matt, when you get some time, please take a look at the updated cinder v3 migrate review. thanks. - https://review.openstack.org/#/c/463987/ | |
| 15:13:37 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 15:13:49 | mriedem | s-dean: is [api_database]connection set in nova.conf when running nova-manage db sync? | |
| 15:13:54 | s-dean | I have created it, Is this a potential bug | |
| 15:14:13 | s-dean | yes my connection string is correct | |
| 15:14:40 | mriedem | s-dean: just to be clear, so you have both [database]/connection and [api_database]/connection set in nova.conf? | |
| 15:14:44 | mriedem | and they are different values, yes? | |
| 15:14:45 | s-dean | yes | |
| 15:14:48 | s-dean | yes | |
| 15:15:08 | s-dean | one for nova_api | |
| 15:15:10 | mriedem | ok, and you ran nova-manage api_db sync ? | |
| 15:15:15 | s-dean | and on for nova db | |
| 15:15:19 | s-dean | yes | |