| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-24 | |||
| 13:42:46 | gibi | mriedem: I will try to dig deeper in oslo.db as time allows | |
| 13:43:15 | bauzas | kashyap: ok, I'll set the bug as confirmed | |
| 13:43:36 | mriedem | gibi: ok | |
| 13:44:49 | bauzas | mriedem: would it be reasonable to target bug reports as pike-rc-potential if anyone didn't provided a fix yet (ie. not in Progress) ? | |
| 13:45:50 | bauzas | mriedem: having in-progress bugs in the bucket is cool for reviews, but I'd also like to make sure we're like telling to the world that the release is worth getting those unassigned bugs fixed so someone could step up ? | |
| 13:46:07 | mriedem | bauzas: yes | |
| 13:46:31 | bauzas | mriedem: tbc, I'm worried of any bad press of https://bugs.launchpad.net/nova/+bug/1705700 if not fixed by Ocata timeframe | |
| 13:46:32 | openstack | Launchpad bug 1705700 in OpenStack Compute (nova) "live migration does not work after volume migration" [High,Confirmed] | |
| 13:47:04 | claudiub | bauzas: we've only observed that bug on hyper-v. libvirt seems to unplug the vifs on confirm_migration. | |
| 13:48:14 | mriedem | bauzas: is it latent or a regression in pike? | |
| 13:48:27 | bauzas | mriedem: it's Ocata | |
| 13:48:47 | mriedem | so a regression introduced in ocata | |
| 13:48:50 | bauzas | mriedem: but looks like https://review.openstack.org/#/c/465205/ was backported to Ocata | |
| 13:49:17 | bauzas | mriedem: I can try to investigate further | |
| 13:49:35 | bauzas | at least the bugfix above was backported in a point release | |
| 13:49:47 | bauzas | we can ask to test some compute with some older release | |
| 13:50:05 | openstackgerrit | sahid proposed openstack/nova-specs master: virt: provide a mask to selection pCPUs to run emu. threads https://review.openstack.org/486617 | |
| 13:50:34 | edleafe | Scheduler subteam meeting in 10 minutes in #openstack-meeting-alt | |
| 13:51:51 | openstackgerrit | Jianghua Wang proposed openstack/nova-specs master: Support virtual GPU resources https://review.openstack.org/450122 | |
| 14:01:30 | edleafe | Scheduler subteam meeting running now in #openstack-meeting-alt | |
| 14:01:48 | openstackgerrit | Sean Dague proposed openstack/nova master: deprecate ``wsgi_log_format`` config variable https://review.openstack.org/486623 | |
| 14:08:42 | artom | kashyap, mdbooth, you mean | |
| 14:09:18 | artom | Err | |
| 14:09:25 | artom | kashyap, mdbooth, you mean https://review.openstack.org/#/c/471356/ ? | |
| 14:09:26 | openstackgerrit | Jay Pipes proposed openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566 | |
| 14:09:34 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Post-migration, set cache value for Cinder volume(s) https://review.openstack.org/485752 | |
| 14:09:46 | artom | This is the yet unmerged newton backport, the other ones have merged | |
| 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 | |