| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-02 | |||
| 14:19:08 | mdbooth | Thanks | |
| 14:21:08 | artom | What would cause a devstack-installed compute to not report to placement? | |
| 14:21:24 | artom | I see it in both hypervisor-list and service list, so it's "in" the cloud | |
| 14:21:30 | jaypipes | artom: spite. | |
| 14:21:36 | mriedem | misconfig | |
| 14:21:40 | artom | But can't boot VMs on it because I see no resource provider for it | |
| 14:21:41 | mriedem | nova-compute can't talk to placement api maybe | |
| 14:21:47 | mriedem | check [placement] section of nova-cpu.conf | |
| 14:21:55 | mriedem | or just read the n-cpu logs | |
| 14:22:07 | mriedem | see channel topic | |
| 14:22:17 | artom | But this is devstack ;) | |
| 14:23:31 | artom | Hrmm, there's *no* [placement] in nova-cpu.conf | |
| 14:23:35 | artom | That would explain things | |
| 14:24:19 | jaypipes | artom: like I said... spite ;P | |
| 14:24:42 | artom | jaypipes, against me or against placement? | |
| 14:25:51 | jaypipes | artom: 42 | |
| 14:28:24 | artom | mriedem, thanks for the pointers, I copied the controller's [placement] to nova-cpu.conf on the compute and fixed it | |
| 14:29:01 | artom | So nova-cpu.conf is new-ish? I haven't actually looked at a devstack in a while. It's for the compute service, presumably? | |
| 14:30:04 | sahid | jaypipes: yep i think you are right on your review. thanks | |
| 14:32:43 | mriedem | artom: been around since pike | |
| 14:32:58 | artom | mriedem, shows how up to date I am :/ | |
| 14:33:11 | jroll | mriedem: gdi, this is why you need a bouncer, meant to ping you on this: https://review.openstack.org/#/c/565736/ | |
| 14:33:20 | jroll | s/meant/tried/ | |
| 14:33:27 | mriedem | artom: i don't know why you'd not have placement configured properly, devstack should have set that all up for you | |
| 14:34:11 | mriedem | gfdi jim, i'm a doctor not a guy that sits up all night waiting for irc pings | |
| 14:34:20 | jroll | heh | |
| 14:34:42 | artom | mriedem, I followed https://docs.openstack.org/devstack/latest/guides/neutron.html, maybe it's out of date for placement? Specifically, ENABLED_SERVICES on the compute | |
| 14:35:12 | mriedem | yes definitely | |
| 14:35:56 | mriedem | placement-client should be in that list | |
| 14:36:00 | mriedem | like https://docs.openstack.org/devstack/latest/guides/multinode-lab.html#configure-compute-nodes | |
| 14:36:33 | artom | mriedem, aha, indeed | |
| 14:37:15 | artom | Shall I apply force to a change in the textual representation of the documentation? | |
| 14:37:30 | mriedem | yes | |
| 14:37:37 | mriedem | be a good citizen | |
| 14:37:52 | artom | Service guarantees citizenship! | |
| 14:38:14 | jaypipes | sahid: ok, cool. test cases should be identical, though, so that's a plus :) | |
| 14:42:30 | Shilpa | stephenfin: Hi | |
| 14:43:39 | stephenfin | Shilpa: o/ | |
| 14:43:47 | kashyap | artom: Also, do post your renewed multi-node configs somewhere | |
| 14:43:56 | jaypipes | mriedem, stephenfin, dansmith: your reviews on https://review.openstack.org/#/c/561315/ would be appreciated. thx in advance :) | |
| 14:44:27 | kashyap | artom: For that poor soul who has to later setup to debug an "urgent" issue | |
| 14:44:30 | Shilpa | stephenfin: i have verified tempest failure for https://review.openstack.org/#/c/550172/3 locally, and added few observations at http://paste.openstack.org/show/720231/, kindly go through the same. | |
| 14:44:37 | kashyap | Mine are here: https://kashyapc.fedorapeople.org/virt/openstack/multi-node-configs/ (But they should be revamped) | |
| 14:44:42 | stephenfin | Shilpa: Can do | |
| 14:45:39 | stephenfin | kashyap: Yup, v2 of that looks much better. Thanks for addressing that. | |
| 14:45:49 | stephenfin | Still have comments on the preceding patch, fyi | |
| 14:45:53 | kashyap | stephenfin: No problem. Thanks for _spotting_ it. | |
| 14:46:05 | kashyap | stephenfin: Oh, I see. Let me look | |
| 14:46:34 | artom | kashyap, sure. The "tricky" bit was the hardware setup | |
| 14:47:29 | artom | Since I need to run on baremetal and don't control the network, I ended up cross-connecting the two machines on a second NIC and setting that as PUBLIC_INTERFACE | |
| 14:47:34 | kashyap | Nested Virt for the win! | |
| 14:47:48 | artom | kashyap, for NUMA live migration? Suuure ;) | |
| 14:47:51 | kashyap | stephenfin: Okido, addressing that too | |
| 14:48:36 | kashyap | artom: For testing PCI device assignment & NUMA, it is possible to an extent: https://www.berrange.com/posts/2017/02/16/setting-up-a-nested-kvm-guest-for-developing-testing-pci-device-assignment-with-numa/ | |
| 14:49:16 | artom | Btw, I spent way too much setting up a thing where I could snapshot my entire devstack OS and revert, in case devstack failed and I needed to go back without having to reinstall from a USB key, but then my stack run essentially worked the first time, so :/ | |
| 14:50:19 | jmccarthy | Although I have my nova repo checked out and 'tox -e py27 -- test_cleanup_resize' tests all pass locally, should these also cover cinder for the case: volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver ? | |
| 14:50:19 | jmccarthy | Hmm I seem to have some behaviour where disk.info shows up on the source host after a resize/cold migrate sort of like this review/bug: https://review.openstack.org/#/c/437356/ | |
| 14:57:02 | Shilpa | stephenfin: if you are busy elsewhere we can discuss the same tomorrow. | |
| 14:57:27 | stephenfin | Shilpa: Yeah, if you wouldn't mind. Have a lot on my plate today | |
| 14:58:04 | Shilpa | stephenfin: no issues, bye for now | |
| 14:58:29 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop BAD_LIBVIRT_CPU_POLICY_VERSIONS https://review.openstack.org/564012 | |
| 14:58:30 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_QEMU_POSTCOPY_VERSION https://review.openstack.org/565724 | |
| 14:58:31 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_REALTIME_VERSION https://review.openstack.org/565707 | |
| 14:59:38 | jmccarthy | s/these also cover cinder/these also cover nova/ | |
| 15:05:22 | melwitt | mriedem: I'll wade through the rebuild thread later | |
| 15:05:40 | melwitt | mriedem: also, thanks for swapping the runway blueprint. I forgot to do it last night | |
| 15:06:18 | mriedem | melwitt: re the rebuild + required image traits thing, at this point for simplicitly i'd probably just concede to the idea of failing in the api if the new image has required traits which aren't in the original image used to create the server | |
| 15:06:34 | mriedem | and then hope that no one ever asks to support that later | |
| 15:06:39 | mriedem | and if they do, you're no longer working on nova | |
| 15:07:52 | melwitt | based on my limited understanding of traits, I don't immediately see why the original image is tied to rebuilding with a new image and why it would need to reject it. so I shall read the thread to learn why :P | |
| 15:10:05 | cfriesen__ | sean-k-m1: sean-k-mooney[m]: do you know the current status of https://blueprints.launchpad.net/nova/+spec/sriov-physical-function-passthrough (where a device can be allocated as either a VF or the full PF) | |
| 15:11:37 | mriedem | melwitt: b/c the host the instance is running on during rebuild is filtered using the original image and it's required traits | |
| 15:12:59 | melwitt | oh, right, because rebuild can't move | |
| 15:13:02 | melwitt | I see | |
| 15:26:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Deprecate the nova-consoleauth service https://review.openstack.org/565367 | |
| 15:28:15 | efried | stephenfin: You gonna go around and change all the other deprecations in the docs? There were about a dozen I counted yesterday. | |
| 15:31:09 | stephenfin | efried: I can but where? | |
| 15:31:56 | efried | stephenfin: I went and looked for them yesterday. I can go find 'em again. | |
| 15:32:06 | efried | stephenfin: But I guess if I'm gonna do that, I may as well fix 'em myself :) | |
| 15:33:19 | shewless | Hi there. I have an instance which is allocated 2GB of RAM but when I look at the qemu process it looks like it's comsuming closer to 8GB of RAM. This is a huge discrepency. Can anyone help me figure out what's going on? | |
| 15:33:34 | shewless | It kind of looks like we are seeing an extra 6GB of memory usage (over what's been allocated) PER instance? | |
| 15:35:55 | stephenfin | efried: That...would make sense, yes :) | |
| 15:36:10 | shewless | I thought that in general a qemu process would use less or equal to what's been provisioned for that instance. Is that wrong? | |
| 15:38:30 | efried | # rgrep -i deprecated doc/source | awk -F: '$1 ~ /rst$/' | |
| 15:38:30 | efried | stephenfin: This produced 29 results, which will need to be inspected manually to see if a .. deprecated:: marker is actually appropriate: | |
| 15:42:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove IronicHostManager and baremetal scheduling options https://review.openstack.org/565805 | |
| 15:42:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove [scheduler]/host_manager config option https://review.openstack.org/565806 | |
| 15:42:35 | mriedem | jroll: ^ | |
| 15:42:44 | jroll | woot | |
| 15:43:04 | sahid | shewless: we know that there are some kind of overheads depending of the number of vCPUs, devices... but 6GB looks crazy, perhaps you should ask #virt in OFTC servers with the exact arguments you are passing to QEMU | |
| 15:43:53 | shewless | sahid thanks I'll check there | |
| 15:45:02 | openstackgerrit | sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 15:45:03 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 15:45:04 | openstackgerrit | sahid proposed openstack/nova master: pci: don't consider case when match tags specs https://review.openstack.org/565808 | |
| 15:50:54 | efried | stephenfin: That deprecated role ain't especially pretty IMO. | |
| 15:51:12 | stephenfin | In what regard? | |
| 15:51:59 | efried | let's see if your delta has rendered yet... | |
| 15:53:11 | efried | stephenfin: http://logs.openstack.org/67/565367/9/check/build-openstack-sphinx-docs/c46fab1/html/cli/nova-consoleauth.html | |
| 15:53:28 | efried | stephenfin: I guess I was expecting a box, like .. note:: | |
| 15:53:33 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: update add-consumer-generation to focus on API https://review.openstack.org/565565 | |