Earlier  
Posted Nick Remark
#openstack-nova - 2025-03-20
14:03:03 opendevreview sean mooney proposed openstack/nova master: raise_forever on wsgi app init https://review.opendev.org/c/openstack/nova/+/945028
14:10:13 sean-k-mooney dansmith: ^ i think is in a pretty good state ill kick off one more recheck via the operator repo to to get fresh result with mod_wsgi but it should be good to review
14:10:20 dansmith I've got it open
17:21:30 gmann bauzas: yes, today I got go ahead from release team about all repo are branched now and I will start the QA tooling (including grenade) setup for old/new releases
17:33:11 bauzas gmann: cool excellent
17:57:21 zigo sean-k-mooney: Hey there! Do you happen to know how far we've been from having the virtiofs driver in Manila? Is it in Epoxy, or should we wait another release ?!?
17:59:01 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
17:59:03 sean-k-mooney zigo: its in
17:59:12 zigo Oh !!! :)
17:59:17 sean-k-mooney zigo: the osc patches for it missed however
17:59:41 zigo sean-k-mooney: Is there anything I should do to support it at the packaging level ?
17:59:51 zigo Or "it just works" (tm) ?
17:59:58 sean-k-mooney so the osc command to attach/detach the share were not merged on time as they are waiting for the sdk patch for the new nova api to land
18:00:46 sean-k-mooney zigo: i dont think it changes any deps or requries packaging work beyond making sure you have the right version of openstacksdk ectra
18:00:50 zigo sean-k-mooney: At this point, I probably will try to get Epoxy in Debian 13, so if there's a (small) series of patches to add, it's probably worth it !
18:01:24 zigo Maybe I should ask in the -discuss list about this topic?
18:01:32 sean-k-mooney they are proposed we proablly will see if we can do a release early in 2025.2 to get the client out there
18:02:14 zigo I'd love it if they were backported to Epoxy officially.
18:02:56 sean-k-mooney https://review.opendev.org/c/openstack/python-openstackclient/+/881540 and https://review.opendev.org/c/openstack/openstacksdk/+/880056 are the pending patches
18:03:32 sean-k-mooney they need a little more work to get over the line hopefully Uggla will have time to work on them again soon
18:04:58 sean-k-mooney zigo: but sure start a mail thread if you want we know completing hte client side fo the various api we added this cycle is a priority
18:05:34 sean-k-mooney we have a couple of gaps for spice-direct, manilla-shared, image properties in server show and server groups in server show
18:05:55 sean-k-mooney all i think have pathces up but we need to work with the clinet fould to get them in shape and landed
19:06:28 mikal zigo: yeah, it would be good to know if Debian 13 had any discussions around dropping SPICE support too. Debian is currently the recommended host OS for hypervisors with spice-direct.
#openstack-nova - 2025-03-21
00:57:50 opendevreview benlei proposed openstack/nova master: optimize process of get connector for swap volume https://review.opendev.org/c/openstack/nova/+/945177
00:57:50 opendevreview benlei proposed openstack/nova master: Abort live migration task when stop nova compute service https://review.opendev.org/c/openstack/nova/+/938223
06:22:11 ishanwar[m] Hi Folks... (full message at <https://matrix.org/oftc/media/v1/media/download/AfIljfPE94kqyEbidICMKCnOaBBquL9y8M186dozy6czq9FKuNXkU37cf0hQWWGf7ByL_Gxne4_JEcywIr82jMNCeV_3bP0QAG1hdHJpeC5vcmcvc2NSRlZCQUlsclpPc2lZWUZuZE9Ramdt>)
06:22:30 ishanwar[m] Can anyone explain how I can find the correct constant
06:22:35 ishanwar[m] * correct constant ?
08:38:57 opendevreview benlei proposed openstack/nova master: FIX: optimize process of get connector for swap volume https://review.opendev.org/c/openstack/nova/+/945177
09:38:04 zigo It's been now 5 years that I opened a merge request for the Nova project to add a /healthcheck from oslo.middleware in the default api-paste.ini. Is this enough time so that the team delcares a "game over" from the team that wanted to improve the oslo.middleware healthcheck before merging ?
09:48:33 frickler zigo: it might help if you include a link to your review (we don't talk about merge requests with gerrit). and yes, without interacting with the community regularly, getting things done is sometimes difficult
09:48:43 zigo https://review.opendev.org/c/openstack/nova/+/724684
09:49:24 gibi zigo: I think the nova team wants to do https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/per-process-healthchecks.html
09:50:07 zigo That's a good thing, though I still need to patch Nova to be able to hook an haproxy to its API, that's kind of annoying.
09:52:52 zigo Especially considering the oslo.middleware healthcheck was implemented in all other projects.
11:02:22 sean-k-mooney zigo: we dont plan to ever use oslo.middleware for healthchefcs as we have stated in the past given its a security risk
11:02:34 sean-k-mooney and doe snot actully do anything useful for nova
11:04:59 sean-k-mooney specificlly the detailed mode is unsafe https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/healthcheck/__init__.py#L159-L160
11:05:48 sean-k-mooney zigo: for any of the apis you can and should hit the microverion endpoint instead
11:06:00 sean-k-mooney which si the root of the api
11:58:28 zigo sean-k-mooney: That's a very silly answer. How do you explain that all other projects do have the /healthcheck and that it works for me?
12:00:35 opendevreview Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks https://review.opendev.org/c/openstack/nova/+/945204
12:05:31 opendevreview Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks https://review.opendev.org/c/openstack/nova/+/945204
12:07:48 ishanwar[m] sean-k-mooney dansmith I have raised a PR based on our discussion in the previous meeting
12:08:11 ishanwar[m] let me know your thoughts
12:27:43 sean-k-mooney zigo: if it works for you your free to ignore out advice and change ti in your downstream packageing, i dont think any project should ever enable it by default
13:02:29 zigo sean-k-mooney: *ALL* projects enabled it by default...
13:02:34 zigo Only Nova refuses to do so.
13:44:02 dansmith sean-k-mooney: I updated this for some verbiage after your last +2, would you mind re-applying? should be easy: https://review.opendev.org/c/openstack/nova-specs/+/943486
13:49:26 opendevreview Dan Smith proposed openstack/nova master: Support glance's new location API https://review.opendev.org/c/openstack/nova/+/891036
14:02:23 sean-k-mooney sorrry was doing somethign else but sure i can look now
14:03:52 sean-k-mooney i did skim v7 the comment gibi had on how you were usign burned we actully my intall reacitno too but then i deciced that since you did not defien the teim i would jsut follow your uasage instead of my internal definition but i generally agreed with that change
14:04:49 sean-k-mooney dansmith: by the way related to the latch term, i starged using bruned because i think of the single use devices like eFueses
14:05:27 dansmith burned is mine!
14:05:32 dansmith but yeah, new rev defines that clearly-er
14:08:24 sean-k-mooney +2w, v8 looks good to me. as an aside are you plannig to move on to the placement swap issue next or complte the integration with the glance api for multiple locations or your change for making glance the enforcer? if the next priortiy is tbd thats fine im just wonderign what you planned ot do next
14:09:26 sean-k-mooney dansmith: im kind of aware thaty you expressed interest in a a few differnet semi high priority issues and it felt like you had a lot on your plate
14:09:27 dansmith sean-k-mooney: so I missed that the locations stuff ever finally landed, and that's partially because I expected the glance people to iterate on my nova patch until it was passing
14:09:30 dansmith but apparently they just merged without it working
14:09:44 dansmith so I just refreshed that and will look at the test results
14:09:48 gibi it is Friday, I'm burned already, needs an external tool applied on me during the weekend to unburn me before I can be used again next week
14:10:01 dansmith gibi: ++ :)
14:10:04 sean-k-mooney lol
14:10:13 dansmith gibi: I'll allow you to use my trademarked term under license :)
14:10:32 sean-k-mooney gibi: can i recommend good food and a audio or phsyical book
14:10:32 gibi understood, send me the necessary invoice
14:10:40 dansmith sean-k-mooney: tbh, I'm pretty steamed about the gpt stuff. I've had that up with cinder, nova, glance changes since last year and I have run out of energy to push people to do simple reviews on it
14:10:47 gibi sean-k-mooney: physical book for sure along with the book :)
14:10:59 gibi sorry along with the food
14:11:06 dansmith sean-k-mooney: so at the moment we're in a reasonable state with image inspection, so I'm not really motivated to push on it at the moment
14:11:18 gibi and sunshine, we are getting proper sunshine here now finally
14:12:20 dansmith sean-k-mooney: the nova side OTU stuff is, I think, ready for some critical review so I'm planning to put up a strawman fix for the placement swap issue in the next week or so so we can argue about all kinds of WWJD lore
14:12:27 sean-k-mooney dansmith: i mean we can chat about it in the ptg or internally but ya it might be better to focus on the things we have control over like placement and see if other can get invovled in teh efforts we dont
14:12:40 dansmith yup
14:12:49 opendevreview Merged openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
14:13:12 dansmith I'm exhausted from pushing people to review, so my hissy fit is to just let it sit.. nobody else will notice, but I'll feel better
14:13:33 sean-k-mooney gibi: same we have had blue skys every morning for the last 2 weeks, cold but clear although they go gray every afternoon
14:14:39 gibi for OTU I'm still planning to a session of local testing with the WIP patch
14:14:39 sean-k-mooney dansmith: speaking of thanks for the constructive review of the mod_wsgi thing. ill try and get the final version ready before i finsh today but no rush to review
14:14:47 gibi *for
14:15:16 dansmith sean-k-mooney: no problem I'm happy with how that has gone for sure and nice to get some quick iterative review
14:15:21 sean-k-mooney if needed i can proably do the same with virual or real hardware
14:15:27 dansmith gibi: cool, thanks
14:16:47 sean-k-mooney dansmith: by the way tehre is one other thing we could consider for the one time ues devices
14:16:59 sean-k-mooney i dont think we should do this
14:17:16 sean-k-mooney bu tlivbirt has an optional deamon that can do device leasing
14:17:48 sean-k-mooney https://libvirt.org/formatdomain.html#device-leases
14:18:15 sean-k-mooney i dont think that helps use because we still need all the placement stuff for schduling
14:18:23 dansmith hmm, but that would encourage people to go direct to libvirt, right? and also, we'd have to sync our state with that in order to .. yeah, scheduling :)
14:19:03 sean-k-mooney right i was going to say the only usecase i see for that is we could take a least and potially never drop it
14:19:22 sean-k-mooney but if we dont refence a lease in our xml i think it ignore it
14:19:40 sean-k-mooney puluse we do not deploy teh relevent deamon in our product downstream
14:19:49 sean-k-mooney so i just wanted to make you aware this exists
14:19:56 sean-k-mooney but i think the soluiton we have is better
14:20:06 dansmith yeah interesting thanks for the pointer
14:52:30 sean-k-mooney dansmith: i kind of know the answer but should i file a new bug for the mod_wsgi thing i have related bug to https://bugs.launchpad.net/nova/+bug/1882094 because it was an incomplete bug fix
14:52:56 dansmith oh that's the previous one huh
14:53:26 sean-k-mooney im trying to see if bogdan filed anything new upstream
14:54:48 dansmith so, it seems like we should have a new bug, yeah, especially if we're going to backport this

Earlier   Later