| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-11 | |||
| 18:36:07 | sean-k-mooney | and then ill proably start playing with it tomorrow or monday | |
| 18:36:33 | melwitt | the admin test is good to verify that it is _possible_ to let admin do stuff if someone wanted that | |
| 18:36:35 | melwitt | but that's all it's for | |
| 18:37:16 | melwitt | ok cool | |
| 18:37:36 | sean-k-mooney | i need to do some prep on the vm fist like install git and clone devstack | |
| 18:37:49 | sean-k-mooney | but that wont thake that long | |
| 18:47:47 | wncslln | hi o/, anyone can help me to enable boot with uefi mode, please? | |
| 18:48:20 | sean-k-mooney | you just need to set hw_firmware_type=uefi in the glance iamge properties i belive | |
| 18:48:32 | sean-k-mooney | oh an hw_machine_type=q35 | |
| 18:48:57 | wncslln | just set this two properties? | |
| 18:48:59 | sean-k-mooney | assuming you have the correct ovmf firmware installed on all your compute nodes | |
| 18:49:31 | wncslln | hmmm i dont think i have | |
| 18:49:32 | sean-k-mooney | yep if you have install the ovmf package on all your compute nodes then qemu will have access to the uefi firmeware | |
| 18:49:57 | sean-k-mooney | https://docs.openstack.org/nova/yoga/admin/uefi.html | |
| 18:51:13 | sean-k-mooney | hw_machine_type=q35 is semi optional | |
| 18:51:40 | sean-k-mooney | qemu considers uefi with the the pc machine type to be experimantal and not recommended | |
| 18:52:05 | sean-k-mooney | most distos dont ship a ovmf fireware that properly supprots it | |
| 18:52:06 | wncslln | i have deployed with kolla-ansible so nova agents are containers. this is a problem? | |
| 18:52:10 | sean-k-mooney | so q35 should be used | |
| 18:52:22 | sean-k-mooney | no i have kolla-ansible at home | |
| 18:52:33 | sean-k-mooney | i am pretty sure there contienres have to correct pakcages already | |
| 18:52:53 | sean-k-mooney | so you just need ot set those tow imagea proepries in glance on the image and it should work | |
| 18:53:03 | sean-k-mooney | assuming the glance iamge supprot uefi | |
| 18:53:14 | sean-k-mooney | the image need to have a gpt partion table and an efi partion | |
| 18:53:24 | sean-k-mooney | same as real hardware | |
| 19:02:26 | wncslln | i setted the properties but the vm wont boot. could be a problem in the image | |
| 19:02:57 | sean-k-mooney | i would try somethign like the latest ubuntu cloud image | |
| 19:03:11 | sean-k-mooney | i think that support uefi boot but its been a while since i tried it | |
| 19:03:16 | wncslln | there is a way to know if the image have a gpt and efi partion? | |
| 19:03:40 | sean-k-mooney | you can download it and inspect it in a vm or with tools like libguestfs | |
| 19:05:30 | wncslln | ok, i'll make some tests here | |
| 19:05:40 | wncslln | sean-k-mooney: thanks for the help | |
| 19:38:46 | wncslln | sean-k-mooney: i found the problem xD probably the image that im using has no uefi/gpt. i downloaded the ubuntu cloud image with support to uefi and worked fine | |
| 19:44:37 | sean-k-mooney | cool | |
| 19:44:54 | sean-k-mooney | ya that make sense a lot of older images wont | |
| 19:45:15 | sean-k-mooney | and if you created it form an iso inn a vm you need to make sure that initall vm is also set up for uefi | |
| 19:45:33 | sean-k-mooney | same for windows as the installers have diffent default based on how the vm was booted | |
| 19:46:31 | wncslln | the image with problem is a snapshot from a vm annndddd probably the old image does not have uefi | |
| 19:50:13 | opendevreview | Merged openstack/nova-specs master: List requested availability zones https://review.opendev.org/c/openstack/nova-specs/+/904368 | |
| 19:54:43 | sean-k-mooney | melwitt: https://paste.opendev.org/show/biqXsY6SO6ePMPosdwIW/ | |
| 20:00:32 | melwitt | sean-k-mooney: that's good right? haha | |
| 20:00:58 | sean-k-mooney | yep https://termbin.com/9tk3 | |
| 20:01:15 | sean-k-mooney | well sort of | |
| 20:01:35 | sean-k-mooney | i copied that config form your raw job | |
| 20:01:48 | sean-k-mooney | so its is using disk encyption | |
| 20:01:54 | sean-k-mooney | and i can log into the vm via the console | |
| 20:02:00 | sean-k-mooney | so it booted fine | |
| 20:02:18 | sean-k-mooney | however its still booting form a qcow with a raw backing file | |
| 20:02:26 | sean-k-mooney | so its not actully checking raw images properly | |
| 20:02:56 | sean-k-mooney | but ya it looks like everything is working correctly other then that. and i booted with both swap and ephmeral | |
| 20:03:28 | sean-k-mooney | im going to leave it there for tonight just wanted to let you knwo i ahve successfuly deployed our code and booted a vm with it | |
| 20:03:31 | melwitt | sean-k-mooney: you have set both use_cow_images = False and images_type = raw? bc if you don't set both it won't do raw | |
| 20:04:06 | sean-k-mooney | images_type=raw or flat | |
| 20:04:32 | melwitt | ok, thanks :) | |
| 20:05:39 | sean-k-mooney | actully im goign to check something | |
| 20:06:00 | melwitt | ok. at least for me if use_cow_images is not set to False, it will do qcow2 instead of raw despite images_type = raw or flat | |
| 20:06:18 | sean-k-mooney | i started with your raw job | |
| 20:06:32 | sean-k-mooney | but i might not have kept that in the local.conf when i finished editing it | |
| 20:07:07 | sean-k-mooney | ok ya | |
| 20:07:12 | sean-k-mooney | i removed that in my editing | |
| 20:07:22 | melwitt | ok. that's the only way I know of that what you're seeing could be happening. if you do have use_cow_images = False then something else is wrong that I haven't seen yet | |
| 20:07:26 | sean-k-mooney | so everything is working as expecte its using qcow for the vms because that is the default | |
| 20:07:54 | sean-k-mooney | no in my local.conf i don thave those set so we are getting the default | |
| 20:08:32 | melwitt | ok I see | |
| 20:09:25 | sean-k-mooney | so cool i wont have time to do much with this tomorrow but ill play around with it on monday and start reivewing the series | |
| 20:09:34 | sean-k-mooney | have you done any multi node testing. | |
| 20:09:38 | sean-k-mooney | i.e. cold/live migration | |
| 20:10:33 | sean-k-mooney | the current zuul jobs seam to be single node | |
| 20:11:39 | sean-k-mooney | on a related note i ported your scater gather patch on to my serise and i got a pretty clean zuul run https://review.opendev.org/c/openstack/nova/+/905285 | |
| 20:12:14 | sean-k-mooney | the main delta between what i have doen is how we monkeypatch | |
| 20:12:43 | melwitt | sean-k-mooney: hm looks like no. I did resize in place. I'll add a multinode job on that patch | |
| 20:13:09 | sean-k-mooney | ok cool ill add a second node and play with that locally too next week | |
| 20:14:38 | melwitt | sean-k-mooney: ok cool. I dunno if you saw I wrote up a comment on the scatter gather patch about how I am seeing requests getting "stuck" on nova-api, like it receives the request and does all the stuff but does not respond. I have seen this in other failures that are not related with my patch too but with the patch it seems to happen much more often | |
| 20:14:58 | sean-k-mooney | ya i did | |
| 20:15:13 | melwitt | oh ok | |
| 20:15:16 | sean-k-mooney | i wanted to see if i saw the same behvior | |
| 20:15:33 | sean-k-mooney | i was wondering if htat coudl be related to how/when monkey patching was done | |
| 20:15:39 | melwitt | ok yeah | |
| 20:15:58 | sean-k-mooney | but there is also this comment on my patch https://review.opendev.org/c/openstack/nova/+/905285/1/nova/compute/multi_cell_list.py | |
| 20:16:02 | sean-k-mooney | that might be related too | |
| 20:16:10 | sean-k-mooney | the timeout might need to be done in the try? | |
| 20:16:28 | sean-k-mooney | or rather the creation or the timer | |
| 20:16:32 | melwitt | that's good. really want to find what/why that's happening | |
| 20:16:42 | melwitt | yeah I was thinking about that too | |
| 20:17:14 | sean-k-mooney | im not familar enough with timers in python to say one way or another but i dont think it would hurt to include it in the try block | |
| 20:18:28 | sean-k-mooney | melwitt: another data point on the previosu patch that uses the standar lib queue https://review.opendev.org/c/openstack/nova/+/900681/8?tab=change-view-tab-header-zuul-results-summary i got a bunch of timeourts | |
| 20:18:35 | sean-k-mooney | but i have not had time to look at way | |
| 20:18:39 | sean-k-mooney | *why | |
| 20:18:49 | melwitt | yeah, agree. it would be safer to move it into the try, I was going to do that anyway. I think I followed this example initially https://eventlet.net/doc/modules/timeout.html#eventlet.timeout.Timeout | |
| 20:19:26 | melwitt | whoa that is a lot of timeouts indeed | |
| 20:21:56 | melwitt | sean-k-mooney: I wasn't sure how to interpret this when I looked at it too, does this mean the eventlet queue does something special to work with greenlets? "The eventlet.queue module implements multi-producer, multi-consumer queues that work across greenlets, with the API similar to the classes found in the standard Queue and multiprocessing modules." https://eventlet.net/doc/modules/queue.html | |
| 20:22:23 | melwitt | if so, that could be why | |
| 20:22:43 | sean-k-mooney | ya so you have done the queue chagne in the same patch that swap to futureist | |
| 20:22:49 | sean-k-mooney | i have them split out | |
| 20:22:55 | melwitt | right, I know :) | |
| 20:23:06 | sean-k-mooney | so it could be related | |
| 20:23:20 | melwitt | I'm saying if eventlet.queue is "special" and you're not using it, maybe queue won't work right. oh, but eventlet should be patching queue right? hm | |
| 20:23:43 | sean-k-mooney | ya i was assuming eventlet was patching it | |
| 20:23:45 | melwitt | if it's patching it I dunno why it wouldn't work 🤔 | |
| 20:23:45 | melwitt | if it's patching it I dunno why it wouldn't work 🤔 | |