| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-24 | |||
| 20:09:47 | outbrito | Yeah, if I install open-iscsi the error ceases. Should that be on bindep then? | |
| 20:14:16 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove use of non-integer/slice indices https://review.opendev.org/c/openstack/placement/+/801104 | |
| 20:14:16 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Update 'select()' calls https://review.opendev.org/c/openstack/placement/+/801103 | |
| 20:14:17 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Use explicit transactions https://review.opendev.org/c/openstack/placement/+/801106 | |
| 20:14:17 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace deprecated 'FromClause.select().whereclause' parameter https://review.opendev.org/c/openstack/placement/+/801105 | |
| 20:14:18 | opendevreview | Stephen Finucane proposed openstack/placement master: tests: Restore - don't reset - warning filters https://review.opendev.org/c/openstack/placement/+/828119 | |
| 20:14:18 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove unnecessary use of '_mapping' https://review.opendev.org/c/openstack/placement/+/801107 | |
| 20:14:19 | opendevreview | Stephen Finucane proposed openstack/placement master: tox: Enable SQLAlchemy 2.0 warnings https://review.opendev.org/c/openstack/placement/+/801108 | |
| 20:14:19 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Use Row, not LegacyRow https://review.opendev.org/c/openstack/placement/+/828305 | |
| 21:50:55 | mloza | Hi, I know it isn't possible to attach a server group to existing VMs that don't have it so I'm asking if it's possible to modify the instance details in the database to add it ? | |
| 23:32:04 | mnaser | mloza: possible? yes -- should you? probably not :) | |
| 23:50:02 | mloza | mnaser: what's the impact ? Another solution besides rebuilding the VMs | |
| 23:50:24 | mnaser | mloza: since you're doing something that is not supported, no one knows what the impact is unfortunately | |
| 23:50:34 | mnaser | you can try it, but if it all breaks, i doubt you'll be able to get much help unfortunately | |
| 23:54:51 | mloza | I know `instance_group_member` table in nova_api db needs to be modified. Is there any other table I'm missing ? | |
| #openstack-nova - 2022-03-25 | |||
| 00:16:52 | opendevreview | Merged openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration' https://review.opendev.org/c/openstack/nova/+/723572 | |
| 00:17:00 | opendevreview | Merged openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest' https://review.opendev.org/c/openstack/nova/+/723573 | |
| 06:21:19 | opendevreview | Merged openstack/nova master: Update contributor guide for Zed https://review.opendev.org/c/openstack/nova/+/833441 | |
| 06:21:24 | opendevreview | Merged openstack/placement master: Add zed spec directory https://review.opendev.org/c/openstack/placement/+/829532 | |
| 13:01:58 | noonedeadpunk | hey there! Any considerations if to use `resources:PCPU` or `hw:cpu_policy='dedicated'` for cpu-pinning? | |
| 13:02:10 | noonedeadpunk | As I just realized they result in quite different xmls | |
| 13:03:04 | noonedeadpunk | In first case through "static" vcpu placement, in second through reall mapping of vCPUs to CPUs... | |
| 13:03:26 | sean-k-mooney | they shoudl result in the same | |
| 13:03:37 | noonedeadpunk | huh | |
| 13:03:50 | sean-k-mooney | both should do a one to one vcpu pinning with the vcpupin element | |
| 13:04:32 | noonedeadpunk | For resources:PCPU I got just <vcpu placement='static'>4</vcpu> | |
| 13:04:40 | noonedeadpunk | and no vcpupin | |
| 13:04:40 | sean-k-mooney | ya that is not correct | |
| 13:04:50 | sean-k-mooney | what release are you on | |
| 13:04:54 | noonedeadpunk | Xena | |
| 13:05:11 | sean-k-mooney | i wonder if the mixed cpu support regressed that | |
| 13:06:07 | noonedeadpunk | maybe I have some mistake in flavor, let me double-check | |
| 13:06:56 | 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:07:07 | 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:20 | sean-k-mooney | its possibe that intoduced a regression but we shoudl have functional test for this | |
| 13:07:48 | noonedeadpunk | Yah I read https://docs.openstack.org/nova/latest/admin/cpu-topologies.html quite carefully :) | |
| 13:08:00 | noonedeadpunk | I just didn't find any difference in there | |
| 13:08:21 | noonedeadpunk | but `hw:cpu_policy='dedicated'` doing correct thing | |
| 13:09:13 | 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:40 | sean-k-mooney | its a thing i know its in wallaby for sure but i think it was before that even | |
| 13:09:45 | sean-k-mooney | so xena has it | |
| 13:10:24 | sean-k-mooney | our functional test are not actully asserting things about the xml at first glace | |
| 13:12:29 | noonedeadpunk | Should we submit bug then? | |
| 13:13:44 | sean-k-mooney | for the pinnign yes please do | |
| 13:13:59 | sean-k-mooney | i was just looking at some other integration tests we have | |
| 13:14:34 | 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:51 | sean-k-mooney | but i think that is only testing the dedicated case not pcpus | |
| 13:15:52 | sean-k-mooney | thats actully just the helper function | |
| 13:15:58 | 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:16:48 | 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:17:06 | noonedeadpunk | yeah, it's testing only dedicated one | |
| 13:18:25 | sean-k-mooney | thanks for binging this up. i normally only test dedicated personally since i dont like using pcpus | |
| 13:18:51 | sean-k-mooney | i suspect when others spot check this form time to time its a simlar story | |
| 13:20:13 | noonedeadpunk | I was just wondering if there's any difference, so decided to try both and was quite surprised about the result) | |
| 13:21:06 | 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:47 | 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:23:11 | noonedeadpunk | oh, ok, I see | |
| 13:23:25 | 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:24:07 | 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:15 | sean-k-mooney | but not terible | |
| 13:24:33 | sean-k-mooney | would you mind providign an xml or sanatised one as part of the bug | |
| 13:24:40 | noonedeadpunk | sure thing | |
| 13:32:52 | noonedeadpunk | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1966452 | |
| 13:34:01 | 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:12 | sean-k-mooney | e.g. <vcpu placement="static">4,6</vcpu> | |
| 13:34:23 | sean-k-mooney | or <vcpu placement="static">4-5</vcpu> | |
| 13:34:57 | sean-k-mooney | once we fix this you coudl fix the vms with a hard reboot and or live migration | |
| 13:34:58 | noonedeadpunk | but vm should have 4 cores actually | |
| 13:35:17 | noonedeadpunk | thankfully, I don't have that in production yet:) | |
| 13:35:20 | sean-k-mooney | oh just saw that | |
| 13:35:26 | sean-k-mooney | <nova:vcpus>4</nova:vcpus> | |
| 13:35:32 | sean-k-mooney | ok this is worse then i taught | |
| 13:36:07 | sean-k-mooney | ok i was going to mark this medium but i think ill triage this as high instead | |
| 13:36:08 | noonedeadpunk | or well, we likely have it until EOD, but jsut use hw:cpu_policy | |
| 13:37:30 | 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:38:51 | 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:40:00 | sean-k-mooney | trait:CUSTOM_HIGHCPU='required are you useing provider.yaml to set that or the cli out of interest | |
| 13:43:13 | noonedeadpunk | CLI | |
| 13:43:39 | sean-k-mooney | ack i dont think we have many using provider.yaml yet so just was wondering if you were | |
| 13:47:05 | noonedeadpunk | nah, not yet:) We already had some traits set in environment, so were following usual path | |
| 15:02:51 | outbrito | G'day folks! | |
| 15:03: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:54 | outbrito | Not very sure how to handle it properly though. Any thoughts? | |
| 15:04:09 | outbrito | I left some options to fix it on the comments | |
| 15:11:10 | sean-k-mooney | that looks like an osbrick issue | |
| 15:11:37 | sean-k-mooney | the unit and func test shoudl not need iscsi | |
| 15:12:20 | sean-k-mooney | so we also shoudl be mocking any calls to os-brick in our unit tests | |
| 15:12:38 | outbrito | I believe theirs don't, but we do mock when we set that global | |
| 15:13:23 | outbrito | https://github.com/openstack/nova/blob/8f250f50446ca2d7aa84609d5144088aa4cded78/nova/test.py#L203 | |
| 15:13:38 | sean-k-mooney | my point wa that this code shoudl nto be running in install or during the tests | |
| 15:13:46 | outbrito | not iscsiadmin anyway, but the lock | |
| 15:14:54 | sean-k-mooney | so none fo this shoudl depend on the os you are on | |
| 16:20:05 | 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:21:28 | mloza | also, is there any reason server group can't be added to running VMs? | |
| 16:34:51 | sean-k-mooney | noonedeadpunk: actully thinking about your pinning bug again i dont think that config enabeld pinning at all | |
| 16:35:13 | sean-k-mooney | that is asking for 4 floating cores | |
| 16:35:28 | sean-k-mooney | it does not have any cores specified in the cpuset atirbute | |
| 16:36:00 | sean-k-mooney | <vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu> is the alternitive way to pin | |
| 16:36:37 | sean-k-mooney | <vcpu placement="static">4</vcpu> just mean 4 cpus | |
| 16:36:49 | 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 | |