Earlier  
Posted Nick Remark
#openstack-nova - 2022-07-12
19:04:49 colby_ sure. Ill get those in place today and let you know if it helps our case at all
19:04:58 sean-k-mooney most of the opencomment are about updating the doc strings but the patch should work as is
19:05:15 sean-k-mooney we might also add a functional repoducer if we can recaret the mdev resue issue
19:05:29 sean-k-mooney colby_: thanks
#openstack-nova - 2022-07-13
04:19:31 opendevreview Kashyap Chamarthy proposed openstack/nova stable/wallaby: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/849610
07:43:06 gibi good morning
09:26:53 opendevreview Maksim Malchuk proposed openstack/nova stable/xena: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/829804
13:28:03 opendevreview Kashyap Chamarthy proposed openstack/nova stable/xena: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/849676
13:35:30 kashyap sean-k-mooney: gibi: Do we always have to backport in order? Is there anything "off" if we backport from master to wallaby, instead of xena to wallaby, when it's a clean pick?
13:36:01 stephenfin kashyap: Always branch by branch
13:36:35 stephenfin It just ensures that people don't skip things. You will invariably have conflicts for anything but the smallest of backports too
13:37:42 kashyap stephenfin: Heya; nod. I just vaguely recall (although my mind is batterred the last few weeks, so I don't trust it) that we've done backport from main to other branches
13:38:24 stephenfin Downstream, perhaps. I don't recall it happening upstream though (intentionally at least)
13:38:51 kashyap Yeah, downstream definitely
14:06:12 opendevreview Andre Aranha proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844
14:06:18 opendevreview Kashyap Chamarthy proposed openstack/nova stable/wallaby: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/849610
14:06:41 kashyap sean-k-mooney: --^ There we go; fixed. Thx for the review!
14:14:29 gibi kashyap: yeah, we need to do it branch by branch. I think tripleo made a decision to EOL some stable branches inbetween active branches
14:14:35 gibi but they are the exception I think
14:15:09 kashyap Nod; thx. I mixed up the downstream way w/ upstream.
14:16:29 sean-k-mooney yes they are the exception but they never followed stable policy and never had the tag in the governance repo
14:16:32 sean-k-mooney we do
14:17:42 gibi ack
16:59:58 colby_ sean-k-mooney: So the patch seemed good yesterday but today I seem to be having trouble reclaiming mdevs again. We were successful yesterday. We do get a different error at least. Previously we just got a message no hosts available. Not we get timeout when building.
17:01:48 colby_ with this on the hypervisor: Insufficient compute resources: vGPU resource is not available
17:02:00 sean-k-mooney ok so perhaps a partial fix.
17:02:18 sean-k-mooney you are seeing that in the nova-compute agent log
17:02:34 colby_ we did notice yesterday that if we tried to spin up right away after delete it would fail and then would work a bit later
17:02:35 sean-k-mooney when its trying to boot?
17:02:40 colby_ yes the nova-compute agent log
17:02:44 sean-k-mooney ack
17:02:59 sean-k-mooney ok that sound like the resuse is still not working
17:03:28 sean-k-mooney it might have fixed the reporting of the resouce to placement
17:03:45 sean-k-mooney but not the consumtion of the exsitng mdev in the driver
17:03:50 colby_ yea and we were able to successfully reclaim some mdevs yesterday
17:04:06 colby_ now its failing and Ive waited a while in case its a caching issue
17:04:15 sean-k-mooney does restarting the comptue agent allow it to work?
17:04:25 colby_ I tried that too. No it got the same error
17:04:29 sean-k-mooney ok
17:04:41 sean-k-mooney so i was wondering if we got out of sync or something
17:05:01 sean-k-mooney like it works after the inital start but then breaks when a perodic runs or something like that
17:05:14 sean-k-mooney colby_: it turns out bauzas is on PTO until monday
17:05:28 sean-k-mooney so i wont be abel to get his input on this until then
17:05:44 sean-k-mooney have you filed an upstream bug for this
17:05:53 colby_ ok no problem. Ill follow up again on Monday.
17:06:08 sean-k-mooney you coudl use the exsiting one but it might be helpful if you could attach the traceback fo the error
17:06:09 colby_ No Im happy to file a bug so that I can get any logs/info they need to help identify
17:06:29 sean-k-mooney ya that could help use create a repoducer test
17:07:10 colby_ So should I create a new one? If so where is the best place to do that?
19:39:41 colby_ sean-k-mooney: should I file a new bug? Where do I do that?
20:25:38 melwitt colby_: you can file a bug from this page https://bugs.launchpad.net/nova
20:26:58 colby_ thanks I was able to find where I needed to do it
20:27:08 colby_ https://bugs.launchpad.net/nova/+bug/1981631
20:48:51 melwitt ok great
#openstack-nova - 2022-07-14
00:26:30 opendevreview Artom Lifshitz proposed openstack/nova-specs master: Configurable instance domains https://review.opendev.org/c/openstack/nova-specs/+/849765
07:38:17 auniyal O/
07:38:37 auniyal tox -e <test> don't always runs same
07:38:40 auniyal tox -re functional-py38 -- regressions.test_bug_1857306.py
07:38:41 auniyal The specified regex doesn't match with anythingERROR: InvocationError for command /opt/stack/nova/.tox/functional-py38/bin/stestr --test-path=./nova/tests/functional run regressions.test_bug_1857306.py (exited with code 1)
07:39:47 auniyal sometime -re works to recreate testing venv, but not always
07:41:20 auniyal tried giving full path as well - nova.tests.functional.regressions.test_bug_1857306.py
07:45:49 gibi auniyal: you don't need the '--' also you should try without the '.py' suffix
07:48:56 auniyal oh yes, removed .py and -- it ran, thanks gibi
07:49:33 gibi the name you give at the end of the tox command is actually a regex matching for the fully qualified name of the test function
08:29:03 sean-k-mooney[m] there is a flag you can pass to use file paths i think
08:29:39 sean-k-mooney[m] but ya by default its a regex of the fully qualified function/module name
08:55:48 opendevreview Stephen Finucane proposed openstack/nova master: etc: Highlight absence of packages from config gen https://review.opendev.org/c/openstack/nova/+/849796
12:08:21 opendevreview Manuel Bentele proposed openstack/nova master: libvirt: Add configuration options to set SPICE compression settings https://review.opendev.org/c/openstack/nova/+/828675
12:09:59 sean-k-mooney gibi: if your about i think this is a fairly simple spec https://review.opendev.org/c/openstack/nova-specs/+/849488 related to ^
12:20:23 stephenfin sean-k-mooney: gibi: specless BP? https://review.opendev.org/c/openstack/nova/+/828675
12:21:26 stephenfin see my comment in there. Personally I'd rather turn on sensible defaults and leave it at that, but perhaps Manuel has a good reason for why we can't do that
12:23:47 stephenfin s/hates/dislikes/
12:24:07 sean-k-mooney stephenfin: they have a spec proposed and it looked good to me so specless or approve the one they have
12:24:48 sean-k-mooney stephenfin: apprently the compression algortiom depends on teh buidl of spice used
12:25:01 sean-k-mooney them mentioned that in the spec comment
12:25:06 stephenfin Oh, nice. I hadn't seen that
12:25:58 sean-k-mooney if there are default that work for most/everyone im also ok to implemnt those and review that in the code patch
12:26:26 sean-k-mooney ah they have auto for most of them as a default
12:26:28 sean-k-mooney cool
12:31:01 stephenfin agreed :(
12:31:05 stephenfin oh well
12:31:09 stephenfin left comments on the spec
12:31:11 stephenfin ...too
12:32:11 sean-k-mooney when you say enable by default
12:32:25 sean-k-mooney its really only enabled by "default" if there is a way to enable something else
12:32:44 sean-k-mooney are you suggesting we hardcode something
12:33:03 sean-k-mooney since i think they had a sane default for basially all the config optiosn
12:35:22 stephenfin sean-k-mooney: Yeah, basically hardcode the defaults they've proposed and don't bother with the knobs
12:35:54 stephenfin unless we have a good reason to add them (e.g. someone would have a good reason to disable that compression)
12:36:04 sean-k-mooney im not really that pushed eitehr way. i assume there is a tradeoff between bandwith and cpu
12:36:14 sean-k-mooney as there almost always is for compression
12:36:54 sean-k-mooney so it might be somthign that an operator wants to optimise for differently depenidn on there usecase
12:38:17 sean-k-mooney stephenfin: https://review.opendev.org/c/openstack/nova-specs/+/849488/3/specs/zed/approved/spice-compression-support.rst#114
12:38:27 sean-k-mooney libvirt apprently has default for this too and that is what they are using
12:38:42 sean-k-mooney as the defalt so hardcoding what they propsoed would be the same as doing nothing
12:39:22 stephenfin hmm, it looks like libvirt's defaults are pretty sane, no?
12:39:28 stephenfin I wonder why they're not good enough
12:40:02 sean-k-mooney again i would guess this comes done to wanting to optimise for wan vs lan vs edge vdi deployments
12:40:32 sean-k-mooney in some cases bandwith might be the costly case in other cpu
12:41:17 sean-k-mooney im really not stongly opionated on this but that is what i was assuming when reviewing

Earlier   Later