| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-13 | |||
| 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 | |
| 12:41:22 | stephenfin | Okay, makes sense. I suspect adding these knobs is the correct decision in that case. I'll just wait for Manuel to pipe up and defend themselves :) | |
| 12:41:33 | sean-k-mooney | ack | |
| 12:41:52 | stephenfin | If nothing else, we'll get better docs on the advantages/disadvantages of configuring these things | |
| 12:42:25 | sean-k-mooney | stephenfin: by the way artom copy pasted your --hostname spec to add --domain and im mostly ok with it but care to have a look at https://review.opendev.org/c/openstack/nova-specs/+/849765 | |
| 12:43:30 | sean-k-mooney | this is related to the whole fqdn in displayname mess | |
| 12:53:07 | stephenfin | reviewed | |
| 12:53:22 | stephenfin | actually, let me have a look through some of the other specs. I missed the spec review day | |
| 13:01:56 | gibi | I have no hard opinion about spice compression. I agree with you to see if we really need this. But if there is a solid use case then I'm OK with having this. | |
| 13:02:19 | gibi | for a spec we are a bit late but I think if this is close then bauzas will not be against landing it next week | |
| 13:03:21 | sean-k-mooney | so we just want to defer the details fo the config options to the code review | |
| 13:04:09 | sean-k-mooney | *do we | |
| 13:09:58 | gibi | If I understand correctly the current default is sane and if we decide not to add knobs then there is nothing to implement. So I think this needs to be decided before the codereview | |
| 13:10:19 | sean-k-mooney | ack that is my understanidng too | |
| 13:10:52 | gibi | so hope Manuel can come back this week or early next week | |
| 13:10:53 | sean-k-mooney | i assuem they wanted to make this change because they had limitation with the current defaults but those are not captured in teh spec | |