| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-01 | |||
| 17:30:01 | mriedem | libvirt might have changed | |
| 17:30:05 | mriedem | re: https://review.openstack.org/#/c/396186/7/lib/nova_plugins/functions-libvirt | |
| 17:30:42 | melwitt | maybe, guh I hope not. I have no clue how that stuff works | |
| 17:30:59 | melwitt | but this used to work and I can't think of anything that's changed | |
| 17:31:00 | mriedem | this is where that check happens http://logs.openstack.org/49/479949/71/check/nova-next/7751dc4/logs/devstacklog.txt.gz#_2018-05-01_15_05_38_543 | |
| 17:31:48 | melwitt | yeah, saw that too | |
| 17:33:53 | melwitt | "no cert file" sounds like it can't find the cert file. it deploys them to /etc/pki/libvirt-vnc/ | |
| 17:34:28 | melwitt | oh wait, but the config says /etc/pki/nova-novnc/ | |
| 17:35:11 | mriedem | looking in the libvirtd logs, i can see qemu being executed with "tls,x509verify=/etc/pki/libvirt-vnc" | |
| 17:36:46 | melwitt | [vnc] | |
| 17:36:46 | melwitt | okay, so I wonder if these are wrong in nova.conf? not sure | |
| 17:36:47 | melwitt | vencrypt_ca_certs = /etc/pki/nova-novnc/ca-cert.pem | |
| 17:37:14 | mriedem | don't know, but that wouldn't really explain how it was working before | |
| 17:37:27 | mriedem | probably need to ask stephenfin or danpb | |
| 17:37:38 | melwitt | yeah, true. I don't even know where teh nova-novnc dir comes from | |
| 17:37:58 | mriedem | it's created by devstack https://review.openstack.org/#/c/396186/7/lib/nova | |
| 17:38:57 | melwitt | fwiw, I was the one who got the devstack patch to actually run with SSL because there were minor things wrong in the devstack changes originally because things had changed over time (the series has been around forever) | |
| 17:39:31 | melwitt | because I didn't want to approve the patches until there was some demonstration of the proxy running with SSL enabled | |
| 17:43:40 | melwitt | wonder if the chown user:group needs to be updated again, that's what I had to change last time https://review.openstack.org/#/c/396186/7/lib/nova_plugins/functions-libvirt@156 | |
| 17:44:06 | mriedem | that's what i was thinking, | |
| 17:44:11 | mriedem | because i had to deal with that for the multiattach stuff | |
| 17:45:11 | mriedem | melwitt: this https://github.com/openstack-dev/devstack/blob/master/stackrc#L630 | |
| 17:45:46 | mriedem | could add a debug patch to make sure that libvirt-qemu exists | |
| 17:46:38 | melwitt | hm, yeah. this would be the qemu user and group. originally it was just qemu:qemu and I had to update it to libvirt-qemu:libvirt-qemu | |
| 17:50:18 | mriedem | melwitt: you should kick an intern to make sure this article from 2011 is up to date https://wiki.libvirt.org/page/VNCTLSSetup | |
| 17:51:19 | melwitt | heh, that's a good doc | |
| 17:54:03 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 17:57:20 | wolverineav | stephenfin: mriedem - updated the review with patch addressing comments ^^ take a look when you get a chance :) | |
| 18:06:24 | openstack | Launchpad bug 522619 in libvirt (Ubuntu) "libvirt launced kvm / qemu system processes run as root by default" [Wishlist,Fix released] | |
| 18:06:24 | melwitt | based on this old bug, it's recommended to use qemu:qemu but it depends on what the distro has done https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/522619 | |
| 18:08:35 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 18:10:33 | mriedem | melwitt: so probably the thing to do is check /etc/group like in stackrc and fallback to qemu:qemu if libvirt-qemu doesn't exist | |
| 18:15:12 | larsks | dansmith: a hack: https://github.com/larsks/os-placement-tools | |
| 18:17:16 | mriedem | tssurya: comments inline | |
| 18:17:31 | tssurya | mriedem: thanks | |
| 18:17:47 | openstackgerrit | Julia Kreger proposed openstack/nova master: ironic: add instance_uuid before any other spawn activity https://review.openstack.org/563722 | |
| 18:19:21 | mriedem | larsks: "--fox" typo | |
| 18:19:58 | larsks | mriedem: hah, you fell for my clever plan. | |
| 18:20:03 | larsks | Also, thanks, fixed it. | |
| 18:20:15 | mriedem | is this for busted migrations? | |
| 18:20:53 | larsks | mriedem: well, maybe. We hit a situation on Friday at boston university where we were unable to schedule new instances on an empty compute node. It turns out there were a number of stale allocations there (and elsewhere in the cluster). | |
| 18:20:59 | larsks | Maybe they were caused by busted migrations? | |
| 18:21:15 | larsks | But this fixed the immediate problem regardless of the cause. | |
| 18:21:16 | mriedem | what version of nova? | |
| 18:21:33 | larsks | It is now pike, but it was upgraded from ocata. And possibly from earlier. | |
| 18:21:42 | mriedem | pike GA or latest stable release? | |
| 18:21:53 | mriedem | post pike GA we found a number of bugs in places where we didn't cleanup allocations properly | |
| 18:21:55 | mriedem | those should all be fixed now | |
| 18:21:57 | larsks | Uh...whatever red hat is distributing in rhel-osp 12. | |
| 18:22:03 | mriedem | heh, fair enough | |
| 18:23:37 | mriedem | https://github.com/larsks/os-placement-tools/blob/master/check_placement.py#L16 is nice | |
| 18:24:11 | larsks | Thanks! | |
| 18:24:14 | dansmith | mriedem: nope | |
| 18:24:41 | dansmith | mriedem: it does coincide with me ruminating about deleting duplicate allocations in -placement last week though | |
| 18:25:27 | mriedem | wonder if anyone ever started on that osc-placement change to orchestrate setting inventory on an entire placement provider aggregate set | |
| 18:25:39 | dansmith | larsks: that looks awesome | |
| 18:25:39 | mriedem | unrelated to this besides placement tooling | |
| 18:25:59 | dansmith | larsks: you should check for instance state and only agree to --fix those in ACTIVE though | |
| 18:26:13 | dansmith | larsks: before ocata (ish?) you could have legit reasons for two allocations for one instance, because that's how we did migrations | |
| 18:26:28 | dansmith | but if the instance is ACTIVE and has two, that'll always need fixing I think | |
| 18:26:35 | dansmith | mriedem: right? | |
| 18:26:43 | mriedem | and/or don't touch any instances with a non-null task_state | |
| 18:26:57 | mriedem | before pike the computes would heal allocations | |
| 18:27:06 | dansmith | yeah | |
| 18:27:23 | mriedem | but yeah don't fix an instance that's undergoing a task_state transition | |
| 18:27:36 | mriedem | yee be warned | |
| 18:31:38 | larsks | So noted. | |
| 18:32:43 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add Project object https://review.openstack.org/565401 | |
| 18:32:44 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add User object to placement modeling https://review.openstack.org/565402 | |
| 18:32:45 | openstackgerrit | Jay Pipes proposed openstack/nova master: add Consumer object https://review.openstack.org/565403 | |
| 18:32:46 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add create() methods to Project, User and Consumer https://review.openstack.org/565404 | |
| 18:32:47 | openstackgerrit | Jay Pipes proposed openstack/nova master: move consumer ensure to API layer https://review.openstack.org/565405 | |
| 18:32:48 | openstackgerrit | Jay Pipes proposed openstack/nova master: remove Allocation.project_id & Allocation.user_id https://review.openstack.org/565406 | |
| 18:32:49 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 18:32:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: increment consumer generation when allocs change https://review.openstack.org/565513 | |
| 18:36:02 | melwitt | looks like libvirt-qemu is the right user and group, actually logged in the devstack log http://logs.openstack.org/49/479949/71/check/nova-next/7751dc4/logs/devstacklog.txt.gz#_2018-05-01_15_04_42_683 | |
| 18:36:26 | mriedem | huh | |
| 18:36:29 | mriedem | nuts | |
| 18:36:54 | melwitt | yeah. back to the drawing board | |
| 18:42:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate the nova-consoleauth service https://review.openstack.org/565367 | |
| 18:43:37 | mriedem | alright https://review.openstack.org/#/q/topic:bp/convert-consoles-to-objects+status:open is ready to go | |
| 18:43:44 | mriedem | and it's the last day in the runway | |
| 18:45:45 | melwitt | so close ... | |
| 18:46:04 | mriedem | well, efried and dansmith can make that magic happen | |
| 18:46:24 | mriedem | *or | |
| 18:46:27 | melwitt | note that once the "convert websocketproxy" change is approved, we need to ask frickler to lift the -2 on the first devstack sandwich change so it can go through | |
| 18:46:33 | mriedem | yup | |
| 18:46:36 | efried | mriedem: subtle. | |
| 18:54:33 | melwitt | dansmith: do you remember why we have to "enable before stop" for the conductor fleet? I had the same thing for the console proxies https://review.openstack.org/#/c/484973/12/lib/nova@1078 | |
| 18:56:50 | dansmith | if the thing isn't enabled, then stop_service won't do anything, | |
| 18:57:08 | dansmith | but I thnk that conductor case was just for when we were moving to super conductor | |
| 18:57:19 | dansmith | although maybe it's still required since we generate the service id for services in the cell? | |
| 19:00:28 | melwitt | I wasn't sure why we can't assume they're enabled from the earlier call to start_nova_console_proxies | |
| 19:01:11 | dansmith | idk, I'm kinda into something else at the moment so I can't look deeply, | |
| 19:01:21 | dansmith | but what I said is what I remember off the top of my head for that stuff | |
| 19:02:45 | melwitt | yeah, np, thanks for that. not looking for a deep answer, wish I had written a comment on here from back when someone explained it | |
| 19:05:18 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: Granular GET /allocation_candidates https://review.openstack.org/517757 | |
| 19:05:27 | melwitt | I think it might be because start_* and stop_* aren't going to happen in the same run (stack.sh vs unstack.sh) and there's not going to be any saving of state about the cell services between those runs | |
| 19:06:20 | melwitt | so during the unstack, you can't stop the per cell processes unless you enable them first | |
| 19:07:41 | dansmith | that's what I'm saying, | |