Earlier  
Posted Nick Remark
#openstack-nova - 2018-05-02
13:49:35 jaypipes sahid: looking at your patch now.
13:52:05 sahid thanks jaypipes, let me know if you need any clarifications
14:02:56 jaypipes sahid: did this bug pop up in a RH customer recently or something?
14:07:52 mriedem arvindn05: efried: jaypipes: bauzas: alex_xu: i've replied on the rebuild + image-defined traits thread; at this point i basically need to detach myself from the issue and ask melwitt or dansmith or others with fresh perspective to weigh in
14:08:00 sahid jaypipes: yes BZ#1519540, basically two issues, one on Nova and the other in libvirt
14:08:08 sahid https://bugzilla.redhat.com/show_bug.cgi?id=1519540
14:08:09 openstack bugzilla.redhat.com bug 1519540 in openstack-nova "nova reporting incorrect available memory" [High,On_dev] - Assigned to sferdjao
14:08:17 efried mriedem: ack
14:15:16 jaypipes sahid: k, reviewed.
14:15:31 jaypipes sahid: I'd be interested in getting stephenfin's eye on that too.
14:17:05 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_QEMU_POSTCOPY_VERSION https://review.openstack.org/565724
14:17:21 kashyap stephenfin: Alright, rewrote the unit test the above way. ^ Clearer?
14:17:44 mriedem mdbooth: looks like it's time for https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers to go into a runway slot, are you going to be around for the next 2 weeks to respond to reviews?
14:18:08 mdbooth mriedem: Yes indeed!
14:19:04 mdbooth I'm out for the next 2 Mondays, but around apart from that and able to work on this.
14:19:04 mriedem done, you've got until the 16th
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 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: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: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 stephenfin: This produced 29 results, which will need to be inspected manually to see if a .. deprecated:: marker is actually appropriate:

Earlier   Later