Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-18
13:18:10 sean-k-mooney haleyb: there is one topic i guess but it does not have to be in the ptg
13:18:35 sean-k-mooney we need a decisoin on how to move forward with https://review.opendev.org/c/openstack/os-vif/+/923036 so we can merge that and finally fix it
13:18:53 haleyb sean-k-mooney: ack regarding the service tokens, i'll at least add it to our agenda as we should plan it
13:19:25 sean-k-mooney haleyb: for now i think you made port bining admin_or_service
13:19:47 sean-k-mooney i think nova already passes a service token alays wen talkign to neutorn
13:20:07 sean-k-mooney so it might already work if we removed the admin role form nova but i dont think anywone has tried
13:20:23 sean-k-mooney i kind o include this in "nova should use the sdk to talk to neutron" topic
13:20:57 sean-k-mooney i.e. so ye can delete python-neutornclient
13:21:07 sean-k-mooney but i dont think that is contoverial
13:21:20 sean-k-mooney it just need people to do it so not sure it need a ptg discussion
13:21:32 haleyb sean-k-mooney: yes, that deprecation is ongoing
16:44:09 opendevreview Stephen Finucane proposed openstack/nova master: [codespell] Fixes for latest version https://review.opendev.org/c/openstack/nova/+/923738
16:44:09 opendevreview Stephen Finucane proposed openstack/nova master: pre-commit: Bump versions https://review.opendev.org/c/openstack/nova/+/923739
#openstack-nova - 2024-10-19
01:10:56 opendevreview norman shen proposed openstack/nova master: Add timeout config for Rados python object https://review.opendev.org/c/openstack/nova/+/932766
08:51:03 opendevreview norman shen proposed openstack/nova master: Add timeout config for Rados python object https://review.opendev.org/c/openstack/nova/+/932766
#openstack-nova - 2024-10-20
00:21:13 opendevreview norman shen proposed openstack/nova master: Add timeout config for Rados python object https://review.opendev.org/c/openstack/nova/+/932766
01:54:49 opendevreview Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876
01:54:50 opendevreview Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877
01:54:50 opendevreview Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844
01:54:51 opendevreview Michael Still proposed openstack/nova master: libvirt: Add extra spec for sound device. https://review.opendev.org/c/openstack/nova/+/926126
01:54:51 opendevreview Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927354
#openstack-nova - 2024-10-21
11:25:25 opendevreview Takashi Kajinami proposed openstack/os-resource-classes master: Drop unnecessary 'x' bit from doc config file https://review.opendev.org/c/openstack/os-resource-classes/+/932878
11:25:38 opendevreview Takashi Kajinami proposed openstack/os-traits master: Drop unnecessary 'x' bit from doc config file https://review.opendev.org/c/openstack/os-traits/+/932879
11:26:41 opendevreview Takashi Kajinami proposed openstack/osc-placement master: Drop unnecessary 'x' bit from doc config file https://review.opendev.org/c/openstack/osc-placement/+/932881
12:40:14 sean-k-mooney HTTP exception thrown: Flavor has hw:virtio_packed_ring extra spec explicitly set to True, conflicting with image which has hw_virtio_packed_ring explicitly set to true.
12:40:19 sean-k-mooney ... well thats a bug
12:40:37 sean-k-mooney we are doing a sting compare somewhere instead of comparing the boolean values
12:43:27 tkajinam https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1120
12:43:35 sean-k-mooney https://bugs.launchpad.net/nova/+bug/2085124
12:44:04 tkajinam this is used not only for boolean properties but also for string properties. We probably have to add a flat to indicate whether the value should be converted before comparison
12:44:37 sean-k-mooney perhaps we have other helpers too
12:44:51 sean-k-mooney i normally expect us to call _get_flavor_image_meta
12:45:05 sean-k-mooney and hten have a spereate funciton per extra spec to chekc it
12:45:12 sean-k-mooney like get_mem_encryption_constraint
12:45:30 sean-k-mooney so we proably used _get_unique_flavor_image_meta to make it simpler but didnt think about this usecase
12:45:43 sean-k-mooney rather then a flavor for conversion we proably need to pass an expected type
12:45:59 sean-k-mooney or convertion function for the flavor value. the image ones are already typed
12:46:17 tkajinam yeah
12:46:25 tkajinam ok the logic for packed_ring is specifically implemented in get_packed_virtqueue_constraint
12:46:30 sean-k-mooney i.e. pass in bool or oslo.utils.str_to_bool whatever taht is called
12:47:48 sean-k-mooney ya so the issue is proably here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1985
12:47:57 sean-k-mooney in that path we are not converting it to the correct type
12:48:16 sean-k-mooney we convert the flavor to the correct type here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1990-L1992
12:48:28 sean-k-mooney but in the dict case the image_value is just a string
12:49:15 sean-k-mooney so we need to call strutils.bool_from_string here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1985
13:54:13 jlejeune hello, I have a question regarding host_mapping, is it "normal" that when we delete a nova-compute service, the 'mapped' field in nova_cell1.compute_nodes table stays at 1 instead of 0 while nova_api.host_mappings related entry is removed ?
13:55:23 jlejeune by letting that 'mapped' field to 1 prevent nova-manage cell_v2 discover_hosts command to create the missing mapping
13:56:37 gibi jlejeune: it sounds like bug #1 in scenario 1 in https://bugs.launchpad.net/nova/+bug/2077070/comments/7
13:57:17 gibi jlejeune: could you check if adding --by-service to the discover_hosts command helps you or not
13:57:21 gibi ?
13:57:41 jlejeune I've already test it and indeed, it "fix" the issue by creating the missing mapping
13:58:14 gibi OK. Then I think it is the same issue.
13:58:32 gibi so yeah, nova should set mapped to 0 when the host mapping is deleted.
13:58:40 jlejeune but not sure I want to do it by service, given the number of computes we have in production
13:59:01 jlejeune agree
13:59:35 gibi if you have time to propose a fix then I'm happy to review it. If not then eventually I get to it myself to propose the fix.
14:01:46 jlejeune I will have a look !
14:02:26 gibi jlejeune: thanks!
14:27:27 jlejeune gibi: maybe we should split the bug in two, one for pci devices and another one for the mapping issue ?
14:31:56 gibi jlejeune: I don't think there is anythin else in the pci side, but if you want a separate bug to fix the mapping issue then sure go ahead and file one. I agree that not mentioning pci devices in the separate bug will help the reviewers not bog down on the pci stuff.
14:34:00 jlejeune yes exactly :)
14:35:43 gibi ping me with the separate bug and I will quickly do the triage of it
14:37:21 jlejeune ok
14:55:02 jlejeune gibi: https://bugs.launchpad.net/nova/+bug/2085135
15:09:46 gibi jlejeune: thank
15:44:06 johnthetubaguy dansmith: are you thinking threads for each task being better for what nova-compute is generally doing? I hadn’t really thought about that. I could see that limiting the code changes, I suppose?
15:44:29 dansmith johnthetubaguy: I want us to at least consider that yeah
15:44:35 bauzas johnthetubaguy: that was something we were considering from the last PTG
15:45:29 dansmith johnthetubaguy: I suspect we have some places where we think we're threadsafe, but aren't
15:45:38 dansmith so we'll need to fix that up, which we should have fixed anyway
15:46:14 dansmith but I think much of nova (potentially conductor as well) could just move straight to real threads, ops can control how much parallelism they want (which they've asked for before) to scale performance, and then we can move on
15:47:17 johnthetubaguy Yeah, I had not thought of it like that. Its a good point.
15:49:06 clarkb just as a point of info zuul runs largely with real threads (I think the websocket lib we use may involve asyncio but I can't remember)
15:49:32 JayF ^ is what dtantsur has been pitching for IPA, although we've written no code in that direction
15:49:38 clarkb it works reasonably well and in theory will work better when we can drop the gil and sort out all of the places we missed extra lockign (but we already coordinate multiple processes with zookeeper so don't really need that scaling approach with dropping gil)
15:50:25 dtantsur Yep. Not all of our project needs to handle an extremely high concurrency.
15:50:40 dtantsur Especially Ironic, which has "I'm busy, come back later" as an inherent part of its API :)
15:51:20 johnthetubaguy Honestly, most of the bugs I find are where we attempt high concurrency badly, hard blocking on some of the API calls and tasks would totally make me operator self happier :)
15:51:25 opendevreview Artom Lifshitz proposed openstack/nova master: libvirt pwr mgmt: reproduce bug 2085122 https://review.opendev.org/c/openstack/nova/+/932922
16:05:12 sean-k-mooney gibi: im not actully sold on usign ayncio for the timout stuff by the way
16:05:38 sean-k-mooney gibi: it was just going to be my next poc, warp the existing fucntion in awaitlet and dispatch ot asyncio on a seperat ethead
16:05:56 sean-k-mooney specificlay for the nova-api sacather gather usecause
16:06:08 dansmith I'm quite sure that doing that will not be a magic bullet unless we're actually running the asyncio event loop
16:06:32 sean-k-mooney right that woudl be idea run the asyncio eventloop in a sperate thread nad dispatch the async task into it
16:06:58 sean-k-mooney again this is just one of the many altertinitve i was condiering
16:07:10 sean-k-mooney im not conviced it is a good approch but its what was suggested in teh wiki
16:07:28 dansmith yeah, but unless we're the parent, I think that the thing that spawned us may receive the SIGALRM and not deliver it to our event loop as a result meaning it doesn't really work like we think if it's blocked in a C call
16:08:06 dansmith anyway, we should dive into a poc and confirm
16:08:13 sean-k-mooney https://wiki.openstack.org/wiki/Eventlet-removal#3._Timeout_and_Deadline_Management_2
16:09:06 gibi sean-k-mooney: for me more moving pieces sounds worse, e.g. awaitlet + asyncio + a worker thread running the eventloop is just too much complexity.
16:09:17 sean-k-mooney i did a poc of this before https://review.opendev.org/c/openstack/nova/+/904425/10/nova/context.py#422
16:09:28 sean-k-mooney with a diffent approch
16:09:35 sean-k-mooney gibi: ack which is valid
16:10:17 sean-k-mooney gibi: i dont think the event approch you suggest really works as we cant assume we can generially check the event within the fucntio we are dispatching
16:10:22 dansmith gibi: ++
16:10:30 sean-k-mooney gibi: sqlachmen does supprot a statement_timeout
16:10:43 sean-k-mooney which i think is going to be the answer for db queies
16:10:54 sean-k-mooney i think this is currently set per session or conenction
16:11:05 gibi sean-k-mooney: my point that we need to make assumption about the functions we run as a task or we need to prepare to abandon them from the gather thread
16:11:07 dansmith sean-k-mooney: "To handle signals the event loop must be run in the main thread."

Earlier   Later