Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-24
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
10:06:47 opendevreview sean mooney proposed openstack/nova stable/2023.2: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945442
10:26:22 sean-k-mooney mikal:ack, i think the vdi enhancments are reasonable, you could files a specless blueprint for it now and added it to todays irc meeting we can see if we can get it approved so you can pick up where you left off
13:04:50 elodilles sean-k-mooney: regarding yesterday's ping about backportability of the 3 patches till caracal ( https://review.opendev.org/c/openstack/nova/+/918089/3 ): to me it looked OK to backport, but reading dansmith's opinion - he has more insight in this, so - it's completely on nova team decision whether an exception to backport this should be granted or not o:) (based on the discussion, backporting to
13:04:56 elodilles prior version than Caracal is not possible in my opinion).
13:09:30 ratailor elodilles, sean-k-mooney, gibi could you please review these, one more +2 is required https://review.opendev.org/c/openstack/nova/+/933107 https://review.opendev.org/c/openstack/nova/+/873901 https://review.opendev.org/c/openstack/nova/+/938054 ?
13:14:06 elodilles ratailor: i don't have +2 right on master branch o:)
13:15:08 ratailor elodilles, ack. no problem. you can provide your suggestion, if you want to. Thanks! :)
13:15:36 elodilles :)
13:25:49 sean-k-mooney ratailor: sure, i need to context switch to somethign else shortly but +2w on https://review.opendev.org/c/openstack/nova/+/933107, im already +2 on https://review.opendev.org/c/openstack/nova/+/938054 so that needs someone else. ill quickly review https://review.opendev.org/c/openstack/nova/+/873901
13:26:16 ratailor sean-k-mooney, sure. Thanks!
13:27:37 sean-k-mooney my commnets on test coverage are still open on https://review.opendev.org/c/openstack/nova/+/873901 but no one has rasied a concern in 3 months so im sort of inlcined to say we can add more later if needed
13:29:48 sean-k-mooney ratailor: what ill do is the following. ill elevate form +1 to +2w but it would be nice if you could submit a followup after this merges for the happy path test i called out and other nits.
13:30:15 ratailor sean-k-mooney, sure. I will do.
13:34:49 opendevreview ribaudr proposed openstack/nova master: FUP Remove unnecessary PCI check https://review.opendev.org/c/openstack/nova/+/944105
13:34:50 opendevreview ribaudr proposed openstack/nova master: FUP improve comment accuracy and variable naming for tag removal https://review.opendev.org/c/openstack/nova/+/943124

Earlier   Later