| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-24 | |||
| 16:58:45 | simondodsley | and this will ensure that SCSI page 83 will be passed through correctly? | |
| 16:59:21 | sean-k-mooney | do you ahve a refence to that defintiion. it will ensure that scsiv3 command are aviable to the guest | |
| 16:59:29 | sean-k-mooney | without that you onlyhave access to v2 commands | |
| 17:02:37 | sean-k-mooney | simondodsley: by the way we only fixed this fucntionaly in recent version of nova | |
| 17:02:47 | sean-k-mooney | i think form dalmation on | |
| 17:03:02 | simondodsley | oh - so it won't work on caracal | |
| 17:03:34 | simondodsley | how did anyone every use windows clustering before this fix then? | |
| 17:03:37 | sean-k-mooney | i can check when we fixed it but no livbirt changed it api because qemu stop supproting the serial atibute with type lun a few years ago | |
| 17:03:58 | sean-k-mooney | windows supprot clustierning with other ways of doing synconisation | |
| 17:04:12 | sean-k-mooney | i.e. not file system absed it has 3-4 modes | |
| 17:04:27 | sean-k-mooney | so either they used one of the other mode or they didnt do it with libvirt | |
| 17:04:51 | sean-k-mooney | i.e. they were usihg hyperv or vmware or ironic | |
| 17:04:52 | simondodsley | this is the error from windows - `Physical disk {} does not have the inquiry data (SCSI page 83h VPD descriptor) that is required by failover clustering. Status: The request is not supported` | |
| 17:05:09 | sean-k-mooney | yep | |
| 17:05:18 | dansmith | that's what lun should fix | |
| 17:05:32 | simondodsley | but it only from dalmation... | |
| 17:05:47 | sean-k-mooney | or really old libvirt | |
| 17:05:52 | dansmith | simondodsley: also, clustered windows is not cloudy and openstack really focuses on cloudy workloads :) | |
| 17:06:08 | dansmith | so that's why it's recent | |
| 17:06:08 | simondodsley | i know that, but tell customers :D | |
| 17:06:12 | dansmith | just saying. | |
| 17:06:55 | sean-k-mooney | so the fix in dalmation was https://github.com/openstack/nova/commit/575ff86a4f1572786d66639f774405fbc074fdb1 | |
| 17:07:07 | sean-k-mooney | which depend on another change that was done in caracal | |
| 17:07:28 | sean-k-mooney | it might be possibel to backport to caracal but not before | |
| 17:07:43 | sean-k-mooney | the prior change i dont think is backportable (using alias) | |
| 17:08:04 | dansmith | not backportable upstream, but doable for simondodsley you mean | |
| 17:08:49 | sean-k-mooney | well if it just needs https://github.com/openstack/nova/commit/575ff86a4f1572786d66639f774405fbc074fdb1 that might be ok upstream but the prior change to use the alias instead of serial to lookup the devices is much more invasive | |
| 17:08:54 | sean-k-mooney | but that already in caracal | |
| 17:09:35 | simondodsley | if we can backport the patch to caracal I can try and convince canonical to apply it downstream as well | |
| 17:10:49 | sean-k-mooney | simondodsley: its a serise of 3 patches https://review.opendev.org/q/topic:%22lun-device-serial%22 | |
| 17:11:03 | sean-k-mooney | simondodsley: i would like to get elodilles input on if that is upstream backporable | |
| 17:18:15 | sean-k-mooney | simondodsley: strictly speaking https://bugs.launchpad.net/nova/+bug/2065084 was a latent bug for years so i think it could be backported upstram but it does not hurt to ask | |
| 17:19:03 | sean-k-mooney | the new feature that was added in caracal that it implcictly depend on is not backportable upstream really | |
| 17:19:26 | simondodsley | just so i haven't got this wrong... from Dalmation we can use `openstack server create --block-device disk_bus=scsi,disk_type=lun,volume_size=x,volume_type=whatever` | |
| 17:19:27 | sean-k-mooney | so if it was backproted it would only be to 2024.1 | |
| 17:19:38 | simondodsley | i thin that backpor would be fine | |
| 17:19:59 | sean-k-mooney | yes taht looks correct to me | |
| 17:20:03 | simondodsley | cool | |
| 17:20:12 | sean-k-mooney | well you might need to set the destination type | |
| 17:20:32 | sean-k-mooney | destination_type=volume | |
| 17:20:55 | sean-k-mooney | you also need to set the source type | |
| 17:21:12 | sean-k-mooney | basically need to set all the filed for the block device mappings for that entry | |
| 17:22:03 | dansmith | sean-k-mooney: what's the justification for backport upstream? it's been broken forever, not sure it ever worked, not a regression in recent memory and thus seems entirely a feature to me | |
| 17:22:52 | sean-k-mooney | dansmith: just that it was tracked as a bug upstream as it worked in theory with old libvirt | |
| 17:23:02 | sean-k-mooney | but i agree that its not a very strong justification | |
| 17:23:23 | sean-k-mooney | that why im relucatnt to propose ti without impot form the stable team | |
| 17:23:35 | sean-k-mooney | e.g. elodilles or others | |
| 17:24:18 | dansmith | okay I thought you were implying it had a good justification.. to me it's just a feature.. if it ever worked it was long enough ago that it's not really a regression, | |
| 17:24:36 | dansmith | so even if it's fixing a bug that never worked, it's enabling a whole new workflow, behaviors, etc.. very feature-y to me | |
| 17:25:11 | sean-k-mooney | yep. canconcal can assesss if they want to fix it in there downstream indepenetely of if we think its upstream fixable too | |
| 17:25:14 | simondodsley | would it elp if a customer raised a bug report against this? | |
| 17:25:19 | sean-k-mooney | so simondodsley i would still reach out to them about it | |
| 17:25:32 | sean-k-mooney | simondodsley: not really we have downstream custoemr bugs relate to it too | |
| 17:25:51 | sean-k-mooney | although it never workined in our downstream that we can tell for any supproted release | |
| 17:26:24 | sean-k-mooney | i.e. its been broekn for many many years | |
| 17:26:32 | simondodsley | i get it | |
| 17:26:58 | sean-k-mooney | we are also debtatign if we can backprot this internally but we have not done that yet | |
| 17:27:39 | sean-k-mooney | our latest downstream product is based on antelope and it does tno have the otehr fature which is the harder oen to backprot safely | |
| 17:28:00 | dansmith | no, a customer bug report would not change my mind :) | |
| 17:28:33 | sean-k-mooney | for what its worth we totelly condier this to be a feature downstream | |
| 17:29:03 | sean-k-mooney | and honestly an incompelte one since you cant use it with attach | |
| 17:30:10 | sean-k-mooney | modifying the nova api to allow setting the device type to lun on attach will need a new microverison and someone to actully do the work :) | |
| 17:31:56 | sean-k-mooney | do be clear that woudl be nice ot have for other reason as it would allwo you to create a volume form an iso and attach it as a cd_rom | |
| 17:32:16 | sean-k-mooney | but i dont think anyone is curently working on that | |
| 18:29:31 | masahito | Hi nova folks, please review the API bug fix https://review.opendev.org/c/openstack/nova/+/939658 All the comments are resolved and i hope bug fix reviews for the next release is open now. | |
| 23:31:42 | sean-k-mooney | melwitt: i shoudl avlid checkign if things have merged before i go to bed :) ill fix the typos quickly `_SentinelExcpetion` was intentionally not `SentinelExcpetion` | |
| 23:32:47 | melwitt | sean-k-mooney: yes you should. that is usually a recipe for staying up even later in my experience :P | |
| 23:33:02 | melwitt | sean-k-mooney: also, I meant typo of the word Exception, not the underscore | |
| 23:33:23 | sean-k-mooney | oh i tried to compare the spelling but i didnt see that | |
| 23:33:33 | sean-k-mooney | ill copy pat your version and add the underscore | |
| 23:33:41 | melwitt | you are very consistent with your typos, I will give you that | |
| 23:34:23 | sean-k-mooney | with in the scope of a function/module | |
| 23:34:51 | sean-k-mooney | if a copiler/interperter shouts at me ill definetly fix it | |
| 23:35:01 | sean-k-mooney | but between files much less so | |
| 23:37:23 | opendevreview | sean mooney proposed openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945028 | |
| 23:37:50 | sean-k-mooney | melwitt: hopefully id didnt add any new typos but ^ shoudl fix everythign you noted | |
| 23:38:22 | sean-k-mooney | ah i reverst the ep to pe | |
| 23:38:51 | sean-k-mooney | *reversed | |
| 23:38:56 | melwitt | sean-k-mooney: looks good to me, thanks | |
| 23:42:01 | sean-k-mooney | by the way is there any reason to hold https://review.opendev.org/c/openstack/nova/+/943507 | |
| 23:42:45 | sean-k-mooney | we are past rc1 and master is not 2025.2 so we can merge that on master but we cant backport until we ship 2025.1 right | |
| 23:43:31 | sean-k-mooney | well backporting is kind if awkware because the config otpion depend on specirfic oslo limits versions | |
| 23:43:56 | sean-k-mooney | but we are past the rc period now so there is no reason not to +w that right? | |
| 23:44:27 | melwitt | sean-k-mooney: yeah, the backport is not straightforward :( so not sure what we will do there, maybe nothing | |
| 23:44:58 | sean-k-mooney | ya thats less the awsome but it what it is | |
| 23:45:15 | melwitt | sean-k-mooney: not that I know of but we could double check with bauzas/uggla | |
| 23:45:44 | sean-k-mooney | i could but i just +w'd i could remove it | |
| 23:45:56 | sean-k-mooney | but i think we are good | |
| 23:46:04 | melwitt | yeah it should be ok | |
| 23:47:23 | sean-k-mooney | i thikn there are 1 or 2 other chanage in a similar state but im not going to go look for them tonight | |
| 23:47:31 | sean-k-mooney | chat to you tomrrow o/ | |
| 23:47:46 | melwitt | seeya tomorrow o/ | |
| #openstack-nova - 2025-03-25 | |||
| 01:33:38 | opendevreview | Merged openstack/nova master: unified limits: discover service ID and region ID https://review.opendev.org/c/openstack/nova/+/943507 | |
| 01:33:44 | opendevreview | Merged openstack/nova stable/2024.1: Reproducer for bug 2098892 https://review.opendev.org/c/openstack/nova/+/942653 | |
| 01:33:51 | opendevreview | Merged openstack/nova stable/2024.1: libvirt: Fix regression of listDevices() return type https://review.opendev.org/c/openstack/nova/+/942654 | |
| 04:35:22 | opendevreview | Merged openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945028 | |
| 08:38:34 | mikal | sean-k-mooney: I added a section to the PTG etherpad for the SPICE VDI next steps. I am not entirely sure it needs a big discussion, but your thoughts would be welcome. | |
| 10:02:40 | opendevreview | sean mooney proposed openstack/nova stable/2025.1: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945439 | |
| 10:04:19 | opendevreview | sean mooney proposed openstack/nova stable/2024.2: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945440 | |
| 10:05:56 | opendevreview | sean mooney proposed openstack/nova stable/2024.1: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945441 | |