| opendevreview | Merged openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration' https://review.opendev.org/c/openstack/nova/+/723572 | 00:16 |
|---|---|---|
| opendevreview | Merged openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest' https://review.opendev.org/c/openstack/nova/+/723573 | 00:17 |
| opendevreview | Merged openstack/nova master: Update contributor guide for Zed https://review.opendev.org/c/openstack/nova/+/833441 | 06:21 |
| opendevreview | Merged openstack/placement master: Add zed spec directory https://review.opendev.org/c/openstack/placement/+/829532 | 06:21 |
| *** mgoddard- is now known as mgoddard | 09:11 | |
| noonedeadpunk | hey there! Any considerations if to use `resources:PCPU` or `hw:cpu_policy='dedicated'` for cpu-pinning? | 13:01 |
| noonedeadpunk | As I just realized they result in quite different xmls | 13:02 |
| noonedeadpunk | In first case through "static" vcpu placement, in second through reall mapping of vCPUs to CPUs... | 13:03 |
| sean-k-mooney | they shoudl result in the same | 13:03 |
| noonedeadpunk | huh | 13:03 |
| sean-k-mooney | both should do a one to one vcpu pinning with the vcpupin element | 13:03 |
| noonedeadpunk | For resources:PCPU I got just <vcpu placement='static'>4</vcpu> | 13:04 |
| sean-k-mooney | ya that is not correct | 13:04 |
| noonedeadpunk | and no vcpupin | 13:04 |
| sean-k-mooney | what release are you on | 13:04 |
| noonedeadpunk | Xena | 13:04 |
| sean-k-mooney | i wonder if the mixed cpu support regressed that | 13:05 |
| noonedeadpunk | maybe I have some mistake in flavor, let me double-check | 13:06 |
| sean-k-mooney | if you have resouces:PCPU it shoudl be all you need although i dont recommend that people use the resouces: syntax in general | 13:06 |
| sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/victoria/implemented/use-pcpu-vcpu-in-one-instance.rst was implemented in victoria | 13:07 |
| sean-k-mooney | its possibe that intoduced a regression but we shoudl have functional test for this | 13:07 |
| noonedeadpunk | Yah I read https://docs.openstack.org/nova/latest/admin/cpu-topologies.html quite carefully :) | 13:07 |
| noonedeadpunk | I just didn't find any difference in there | 13:08 |
| noonedeadpunk | but `hw:cpu_policy='dedicated'` doing correct thing | 13:08 |
| noonedeadpunk | Another question - I do remember some changelog, that suport of live migration for pinned instances was added - was I dreaming or it's a thing? | 13:09 |
| sean-k-mooney | its a thing i know its in wallaby for sure but i think it was before that even | 13:09 |
| sean-k-mooney | so xena has it | 13:09 |
| sean-k-mooney | our functional test are not actully asserting things about the xml at first glace | 13:10 |
| noonedeadpunk | Should we submit bug then? | 13:12 |
| sean-k-mooney | for the pinnign yes please do | 13:13 |
| sean-k-mooney | i was just looking at some other integration tests we have | 13:13 |
| sean-k-mooney | whitebox has test to assert the xml generateion https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/api/compute/test_cpu_pinning.py#L94-L110 | 13:14 |
| sean-k-mooney | but i think that is only testing the dedicated case not pcpus | 13:14 |
| sean-k-mooney | thats actully just the helper function | 13:15 |
| sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/api/compute/test_cpu_pinning.py#L143-L172 is one of the test | 13:15 |
| sean-k-mooney | noonedeadpunk: i was going to try and create a func test to repoduce something else but ill see if i can trigger this too. | 13:16 |
| noonedeadpunk | yeah, it's testing only dedicated one | 13:17 |
| sean-k-mooney | thanks for binging this up. i normally only test dedicated personally since i dont like using pcpus | 13:18 |
| sean-k-mooney | i suspect when others spot check this form time to time its a simlar story | 13:18 |
| noonedeadpunk | I was just wondering if there's any difference, so decided to try both and was quite surprised about the result) | 13:20 |
| sean-k-mooney | ya am one question its still emiting the vcpu top level element and listing the n host cpus in the cpuset that were allcoated to the vm right | 13:21 |
| sean-k-mooney | libvirt will internally generate vcpupin element but the behavior it will have is to let the cpu of the guest float over the n cpus in the set | 13:21 |
| noonedeadpunk | oh, ok, I see | 13:23 |
| sean-k-mooney | so the vm shoudl still be pinned to a dedicated set of cores that other vms wont use but each guest cpu wont be be pinned to a speicic core but a set of cores | 13:23 |
| sean-k-mooney | that will potentally still have latency issue if the host schduer decided to move the vcpu threads between the cores so not ideal | 13:24 |
| sean-k-mooney | but not terible | 13:24 |
| sean-k-mooney | would you mind providign an xml or sanatised one as part of the bug | 13:24 |
| noonedeadpunk | sure thing | 13:24 |
| noonedeadpunk | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1966452 | 13:32 |
| sean-k-mooney | <vcpu placement="static">4</vcpu> so ya that will still pin it but if that vm had 2 cores for exampel that woudl then be a range or list of hosts | 13:34 |
| sean-k-mooney | e.g. <vcpu placement="static">4,6</vcpu> | 13:34 |
| sean-k-mooney | or <vcpu placement="static">4-5</vcpu> | 13:34 |
| sean-k-mooney | once we fix this you coudl fix the vms with a hard reboot and or live migration | 13:34 |
| noonedeadpunk | but vm should have 4 cores actually | 13:34 |
| noonedeadpunk | thankfully, I don't have that in production yet:) | 13:35 |
| sean-k-mooney | oh just saw that | 13:35 |
| sean-k-mooney | <nova:vcpus>4</nova:vcpus> | 13:35 |
| sean-k-mooney | ok this is worse then i taught | 13:35 |
| sean-k-mooney | ok i was going to mark this medium but i think ill triage this as high instead | 13:36 |
| noonedeadpunk | or well, we likely have it until EOD, but jsut use hw:cpu_policy | 13:36 |
| sean-k-mooney | ya the workaroudn is to use hw:cpu_policy dedicated which is my perfered option anyway so i don think this need to be critical but its valid and a high impact to performance | 13:37 |
| sean-k-mooney | i have devstack running currently on my home server so ill see if i can recreate with master and we can go from there | 13:38 |
| sean-k-mooney | trait:CUSTOM_HIGHCPU='required are you useing provider.yaml to set that or the cli out of interest | 13:40 |
| noonedeadpunk | CLI | 13:43 |
| sean-k-mooney | ack i dont think we have many using provider.yaml yet so just was wondering if you were | 13:43 |
| noonedeadpunk | nah, not yet:) We already had some traits set in environment, so were following usual path | 13:47 |
| *** artom__ is now known as artom | 14:14 | |
| *** dasm|off is now known as dasm | 14:38 | |
| outbrito | G'day folks! | 15:02 |
| outbrito | About the problem I had running tox the other day, I filed this bug: https://bugs.launchpad.net/nova/+bug/1966477 | 15:03 |
| outbrito | Not very sure how to handle it properly though. Any thoughts? | 15:03 |
| outbrito | I left some options to fix it on the comments | 15:04 |
| sean-k-mooney | that looks like an osbrick issue | 15:11 |
| sean-k-mooney | the unit and func test shoudl not need iscsi | 15:11 |
| sean-k-mooney | so we also shoudl be mocking any calls to os-brick in our unit tests | 15:12 |
| outbrito | I believe theirs don't, but we do mock when we set that global | 15:12 |
| outbrito | https://github.com/openstack/nova/blob/8f250f50446ca2d7aa84609d5144088aa4cded78/nova/test.py#L203 | 15:13 |
| sean-k-mooney | my point wa that this code shoudl nto be running in install or during the tests | 15:13 |
| outbrito | not iscsiadmin anyway, but the lock | 15:13 |
| sean-k-mooney | so none fo this shoudl depend on the os you are on | 15:14 |
| mloza | I know this isn't supported but I wanted to add server group to running VMs, I found `instance_group_member` table in nova_api needs to be modified. Any other tables I missed? | 16:20 |
| mloza | also, is there any reason server group can't be added to running VMs? | 16:21 |
| sean-k-mooney | noonedeadpunk: actully thinking about your pinning bug again i dont think that config enabeld pinning at all | 16:34 |
| sean-k-mooney | that is asking for 4 floating cores | 16:35 |
| sean-k-mooney | it does not have any cores specified in the cpuset atirbute | 16:35 |
| sean-k-mooney | <vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu> is the alternitive way to pin | 16:36 |
| sean-k-mooney | <vcpu placement="static">4</vcpu> just mean 4 cpus | 16:36 |
| dansmith | mloza: we don't do it because of the affinity policies, if we just let you add them you could violate those, and we're not going to move things around to keep the policies straight | 16:36 |
| sean-k-mooney | so ya resouces:PCPUs is totally broken | 16:37 |
| opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Move implemented specs for the Yoga release https://review.opendev.org/c/openstack/nova-specs/+/835272 | 16:40 |
| noonedeadpunk | sean-k-mooney: I just noticed a typo in flavor :( | 16:47 |
| noonedeadpunk | So I just wasted your time likely | 16:48 |
| sean-k-mooney | i havent spendt much on it yet currently debuging downstream issue and devstack problems | 17:05 |
| sean-k-mooney | i was just looking at a different xml an realise i read your one wrong the first time | 17:05 |
| sean-k-mooney | noonedeadpunk: if there isnt an issue great but we found we are missing coverage in whitebox in either case | 17:06 |
| sean-k-mooney | noonedeadpunk: if the bug is not required feel free to close it but if its still does not work after you fix the typo let me know | 17:16 |
| sean-k-mooney | oh s/resouces/resources/ | 17:17 |
| sean-k-mooney | ya i would never spot that | 17:17 |
| *** dasm is now known as dasm|off | 19:14 | |
| opendevreview | Merged openstack/nova master: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/833166 | 21:24 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!