| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-02 | |||
| 16:15:22 | noonedeadpunk | client also does pass bunch of filters: /v2.1/servers/detail?flavor=None&image=None&name=None&project_id=None&reservation_id=None&status=None&user_id=None&deleted=False&host=None&ip=None&ip6=None&changes-since=None&changes-before=None&all_tenants=True | |
| 16:15:34 | noonedeadpunk | so I wonder if that might be client that I've upgraded | |
| 16:15:56 | sean-k-mooney | you could try doing it with nova client or installing an older osc in a venv | |
| 16:16:09 | sean-k-mooney | that woudl at least tell us if its server or client side | |
| 16:16:12 | noonedeadpunk | or just do REST call | |
| 16:16:17 | sean-k-mooney | yep or that | |
| 16:16:40 | sean-k-mooney | you can do it with curl if you have a keyston token but i always have to look up the syntax | |
| 16:19:42 | noonedeadpunk | so curl takes half of the time, as I assume osc does fetch more info to render uuids | |
| 16:20:04 | noonedeadpunk | still 1m24s while haproxy used to be set to 60s timeout | |
| 16:20:37 | noonedeadpunk | and request was `time curl -g -i --cacert "/etc/ssl/certs/ca-certificates.crt" -X GET "http://cloud.com:8774/v2.1/servers/detail?all_tenants=True" -H "Accept: application/json" -H "X-Auth-Token: ${token}" -H "X-OpenStack-Nova-API-Version: 2.92"` | |
| 16:26:44 | sean-k-mooney | if you have the request id it would be good to check how long the request taks on the nova-api side | |
| 16:27:12 | sean-k-mooney | /server/detail is not the same as /server | |
| 16:27:33 | sean-k-mooney | so if you dont want all the addtional info avoid /server/detail | |
| 16:28:26 | noonedeadpunk | well, I'm not sure about detail part, but assume it was preffered to limit amount of following requests. | |
| 16:28:40 | noonedeadpunk | but also interesting to find | |
| 16:29:12 | sean-k-mooney | well /detail is not really advisabel on large cloud if using --all-tenatns | |
| 16:29:35 | sean-k-mooney | it can inovled calls to neutron or other sirvices for info in some cases | |
| 16:29:59 | sean-k-mooney | we mostly try to cache some of that info but we dont cache all of it | |
| 16:34:27 | sean-k-mooney | i am thinking of https://bugs.launchpad.net/nova/+bug/1923560 | |
| 16:34:43 | sean-k-mooney | without https://review.opendev.org/c/openstack/nova/+/786348 we need to do a call to neutron for every server | |
| 16:34:53 | sean-k-mooney | if you use /server/detail | |
| 17:41:02 | opendevreview | sean mooney proposed openstack/nova master: enable numa live migration in the ceph job https://review.opendev.org/c/openstack/nova/+/913842 | |
| 17:41:36 | opendevreview | sean mooney proposed openstack/nova master: enable numa live migration in the ceph job https://review.opendev.org/c/openstack/nova/+/913842 | |
| 22:53:43 | opendevreview | sean mooney proposed openstack/nova master: [DNM] testing rdo experimental jobs https://review.opendev.org/c/openstack/nova/+/927762 | |
| #openstack-nova - 2024-09-03 | |||
| 00:56:17 | opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Followup fixes around flavor ids https://review.opendev.org/c/openstack/nova/+/927764 | |
| 01:39:54 | stan | Guys can I set a limit of how many VMs can be created simultaneously? Let's say if the user wants to create 20 VMs at a time, is there a mechanism to create 5vms in the first batch, and put the rest of the vm request in queue? | |
| 01:45:21 | bauzas | I officially called out the FeatureFreeze | |
| 01:45:40 | bauzas | all the 2024.2 blueprints are now either Deferred or Implemented | |
| 01:45:53 | bauzas | numbers aren't great, tbh. | |
| 01:46:47 | bauzas | https://blueprints.launchpad.net/nova/2024.2 | |
| 06:33:08 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | |
| 06:33:09 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | |
| 07:34:25 | opendevreview | Viktor Křivák proposed openstack/nova master: Ensure claims to placement are freed after evacuate complete Improve resource_tracker delete_allocation_for_evacuated_instance to handle non-cached compute hosts Fix test to accept this change https://review.opendev.org/c/openstack/nova/+/926292 | |
| 09:05:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | |
| 09:05:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | |
| 10:43:59 | sean-k-mooney | stan: not on a per user basis or at teh api level | |
| 10:44:08 | sean-k-mooney | stan: you can set a limit per compute node | |
| 10:44:37 | sean-k-mooney | it defaults to 10 https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.max_concurrent_builds | |
| 10:59:37 | stan | sean-k-mooney Thanks for the information. :) | |
| 11:04:08 | stan | I assume I can make changes to this in combination with scheduler timeout to achieve our use case. | |
| 11:04:30 | sean-k-mooney | note really | |
| 11:04:52 | sean-k-mooney | the compute node config only takes effect after the instance is schduled and just delays it spawning | |
| 11:17:38 | stan | sean-k-mooney Alright. I will test this in our lab 👍 | |
| 11:30:02 | stan | sean-k-mooney So nova timeout will effectively come into play after its schedule or after the VM starts to spawn? | |
| 11:30:46 | sean-k-mooney | no | |
| 11:31:36 | sean-k-mooney | there are a few tiemouts at play. there is an api request time out for the intiall http respocne, then there is the rpc timeout between the conductor schduelr adn computes | |
| 11:32:04 | sean-k-mooney | and then there is an instance build timeout https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.instance_build_timeout | |
| 11:32:23 | sean-k-mooney | which defaults ot 0 meaning no limit | |
| 12:16:56 | sean-k-mooney | dansmith: looks like we have another test that should be skiped without qemu-img | |
| 12:16:58 | sean-k-mooney | https://paste.opendev.org/show/bOFlCycmdpOV1shHsHQX/ | |
| 12:17:36 | sean-k-mooney | did we plan to merge your patch to use the oslo version? i lost track of where we were with that | |
| 12:29:51 | jlejeune_ | sean-k-mooney: hello, indeed, that's why I've proposed: https://review.opendev.org/c/openstack/nova/+/925208 | |
| 12:30:16 | sean-k-mooney | ah yes i tought this was familar | |
| 12:30:23 | jlejeune | sean-k-mooney: :) | |
| 12:31:12 | sean-k-mooney | i am usign distobox to create a clean dev env on my laptop to workaround some packaging issues so didnt have it installed | |
| 12:31:48 | jlejeune | like on our CI | |
| 12:32:27 | sean-k-mooney | well in the first party ci we do have qemu-img isntalled | |
| 12:32:35 | sean-k-mooney | but in general it should not be requried | |
| 12:33:22 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/925208/comment/2b6ac8e7_286f92b1/ is still an open question that needs input form others | |
| 12:34:47 | sean-k-mooney | im ok with the stub as i dont think the existin unit test should be executing that code but we still need others to weigh in | |
| 12:35:19 | sean-k-mooney | jlejeune: to be honest i had tought we merged that already | |
| 12:36:09 | jlejeune | I know I have some work to do to tka in consideration your comment but I didn't have time to work on | |
| 12:36:28 | sean-k-mooney | thats fine we didnt have time to review it | |
| 12:46:13 | jlejeune | ok so I don't change my code and let someone else review it based on your opinion ? | |
| 12:55:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Replace deprecated glanceclient exception https://review.opendev.org/c/openstack/nova/+/914761 | |
| 13:04:16 | sean-k-mooney | jlejeune: dan has a stonger prefernce then i do. i was ok with the reductionin code execution because i dont think a unit test should be as large as that one is and the coverage shoudl eb provided by smaller more targed test or or functional test suite | |
| 13:32:47 | dansmith | sean-k-mooney: yes, merged, and that trace isn't in my code | |
| 13:33:08 | sean-k-mooney | dansmith: i know its just a missing mock | |
| 13:36:13 | dansmith | okay, I'm not sure what you're asking | |
| 13:37:34 | sean-k-mooney | i was just letting you knwo we still have once ase where its not mocked and jlejeune remindiend me that we had dicussed this on tehre patch previously https://review.opendev.org/c/openstack/nova/+/925208 | |
| 13:56:44 | jlejeune | sean-k-mooney: dansmith: not sure what I have to do about it now :) | |
| 13:59:08 | dansmith | tbh, I don't hate the very first rev of this patch, and I think it's better than the current one | |
| 13:59:22 | dansmith | I would str(e) and make sure there's a qemu-img in there so we only skip for that case | |
| 13:59:33 | dansmith | but that leaves us all the coverage we have today on systems that can test it, | |
| 13:59:42 | dansmith | and just skips it for limited environments | |
| 13:59:53 | dansmith | just like our opportunistic DB testing | |
| 14:07:34 | dansmith | jlejeune: ^ | |
| 14:11:59 | jlejeune | dansmith: ok, you mean I had to check the str(e) of the exception to detect if it's really related to qemu-img, in my first patchset ? | |
| 14:12:11 | dansmith | jlejeune: yeah | |
| 14:12:21 | jlejeune | ok clear, doing, thanks | |
| 14:12:27 | dansmith | sounded like sean-k-mooney was not okay with that approach though, but I'm not sure why.. it keeps the most coverage | |
| 14:12:39 | dansmith | jlejeune: might want to wait for sean-k-mooney to say that's okay as well | |
| 14:12:45 | jlejeune | ok | |
| 14:13:18 | sean-k-mooney | dansmith: i not entirly against it but form my point of view the unit test is not a unit test today | |
| 14:13:43 | sean-k-mooney | unit tests should not be calling code out side of the same call liek that | |
| 14:14:03 | sean-k-mooney | if you think we have a clean way to keep the coverage and make this work that you are happy with then thats fine | |
| 14:14:41 | dansmith | sean-k-mooney: you can argue that, sure, and I'm sure these exist since before the functional split, but unless you want jlejeune to refactor and move them out to functional, it seems like a reasonable "just fix the problem without the nuclear option of losing a bunch of coverage (regardless of the quality)" option | |
| 14:15:41 | sean-k-mooney | its a trade off between fragile tests and test coverage | |
| 14:16:06 | sean-k-mooney | dansmith: i dont have the review open right now but did the coverage report show a decresse in coverage? | |
| 14:16:48 | sean-k-mooney | a hte resulsts expired | |
| 14:16:53 | dansmith | sean-k-mooney: the only way it wouldn't is if we have all that code covered and mocked elsewhere, but the point of this test is to have some basic exercising of those things, | |
| 14:17:11 | dansmith | so that if we were to remove the specific tests we'd at least have this | |
| 14:17:12 | sean-k-mooney | dansmith: i dont think refactoring into the funcitonal test is a reasonable ask so i agree we shoudl just fix the exiting test for now | |
| 14:17:32 | dansmith | sean-k-mooney: right, me either, I was just using that to make the point :) | |
| 14:17:43 | sean-k-mooney | dansmith: ok so i disagree that that shoudl be its point | |
| 14:17:59 | sean-k-mooney | it should be testing the hihgh level interface | |
| 14:18:09 | sean-k-mooney | adn the lower leves shoudl be coverd elsewhere | |
| 14:18:23 | sean-k-mooney | btu for now if your happy with yoru proposed solution then lets proceed with that | |
| 14:18:27 | dansmith | again, I don't disagree with the "should" part.. just don't want to lose the "is currently" part | |
| 14:19:55 | sean-k-mooney | so you want to go back to https://review.opendev.org/c/openstack/nova/+/925208/1/nova/tests/unit/virt/test_virt_drivers.py then and add a check that the excption has qemu-img in it | |