| opendevreview | Takashi Kajinami proposed openstack/placement master: Drop db migration tool https://review.opendev.org/c/openstack/placement/+/932324 | 01:40 |
|---|---|---|
| opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Revert "Test live migration between hosts with differnet cpu_shared_sets" https://review.opendev.org/c/openstack/nova/+/932379 | 07:02 |
| gibi | sean-k-mooney[m]: melwitt: I skimmed the discussion above above about the threading in scatter gather. Yes, my comment about the timer was only about the proposed native thread based code. | 07:17 |
| gibi | also please note in native threading there is no such thing that having a timer in an existing thread. The timer itself is always a seperate thread (with basically a sleep and a callback). So if we want a threading.timer based solution to signal an existing thread we need a communication channel between the timer thread that runs our callback on timeout and the existing thread that needs the timer | 07:19 |
| gibi | signal. The most simple thing is to share an Event between the two threads. All the solution needs the existing thread to monitor some channel (e.g. the Event) periodically. | 07:19 |
| sean-k-mooney[m] | an event wont work as far as im aware since the event wont raise an excpetion unless we check it | 07:31 |
| sean-k-mooney[m] | also isint the time just a syscall to the OS to have the OS signal the thread after a timer interupt fires | 07:31 |
| sean-k-mooney[m] | hum, maybe a https://docs.python.org/3/library/threading.html#threading.Barrier is closer to what we want | 07:36 |
| sean-k-mooney[m] | the main issue is we dont really have a concpet of a frestandign cancelable task | 07:36 |
| sean-k-mooney[m] | that what we really want | 07:36 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Repropose spice-direct console support. https://review.opendev.org/c/openstack/nova-specs/+/932387 | 07:45 |
| sean-k-mooney[m] | gibi: the first example here https://www.geeksforgeeks.org/python-different-ways-to-kill-a-thread/ could be adapted for our use | 07:46 |
| sean-k-mooney[m] | we can wrap the function into a calss with an overloaded call operator and add a function to raise the excption | 07:47 |
| sean-k-mooney[m] | then we can use the current timeout code to invoke that function if it expires | 07:47 |
| sean-k-mooney[m] | ill see if i can come up with a restandign example of that and we can see what we think of the approch | 07:54 |
| gibi | sean-k-mooney[m]: threading.Timer is a thread not an OS signal based construct https://github.com/python/cpython/blob/546dddca43a2a69dbe33d230e9e540636b403270/Lib/threading.py#L1318-L1343 | 09:29 |
| sean-k-mooney | gibi: ya i read the docs on it after | 09:30 |
| sean-k-mooney | its a subclass of thread | 09:30 |
| gibi | sean-k-mooney[m]: python has signal handling if we want but that require special care as signal handlers can only run in the main thread and can be tricky to write them properly | 09:30 |
| sean-k-mooney | no im in two minds | 09:30 |
| gibi | https://docs.python.org/3/library/signal.html#signal.SIGALRM | 09:31 |
| sean-k-mooney | part of me wonders if the current approch is corect | 09:31 |
| sean-k-mooney | i.e. are we trying to handle this in too generic a way | 09:31 |
| sean-k-mooney | the only reason this timeout exist sis to timeout the db query to the cell db | 09:31 |
| sean-k-mooney | so im partly wonderign if sqlachemy has a native way to do that | 09:31 |
| gibi | yeah, we can step back and look at the current use case to see if we can reformulate it | 09:32 |
| sean-k-mooney | on the other hand if we dont and we want a generic killable way to execute a task a process is better for that | 09:32 |
| gibi | what we want is a to limit the API response time which a) is limited by the web server (haproxy) already I guess and b) avoid stuck threads waiting for a result that never arrives. | 09:33 |
| sean-k-mooney | yep we have a few options, create a task obejct that will execute an arbitry funciton but kill itself after a timeout, run the function in a process and kill it outselves, convert it to a asyncio corutine and cancel it after a timeout or use somethign in sqlacment to kill it after a timeout at the low level | 09:35 |
| gibi | Do we know how many places in nova we rely on the eventlet in process timer? If it is just 2-3 places then it make sense to do a specific solution for each, if it is more than 5 then I would vote for a creation of a cancellable task primitive and use that everywhere | 09:39 |
| sean-k-mooney | thats a good question. This query_wrapper function is only used in one place i belive | 09:40 |
| sean-k-mooney | im not sure if we have this patterin in ohter however | 09:40 |
| sean-k-mooney | im currently trying to play with creating a BoundTask class to do that | 09:41 |
| sean-k-mooney | maybe TimerTask naming is hard | 09:41 |
| gibi | I guess we have timers in the compute for e.g. vif_plug events | 09:41 |
| sean-k-mooney | yes but it depend on how they are used | 09:42 |
| sean-k-mooney | what i want to do and other can disagree | 09:42 |
| sean-k-mooney | is have our main loop handel pooling for RPC messages | 09:42 |
| sean-k-mooney | but dispatch the message handler to a worker thread pool | 09:43 |
| sean-k-mooney | so basiclaly each RPC handlelr woudl be spawned into its own thread which it can freely block on | 09:43 |
| gibi | I'm not sure how oslo.messaging works in threading mode, I assumed it already does the dispatch of messages to separate threads (from a pool) | 09:43 |
| sean-k-mooney | ya im kind fo hoping it does but not sure either | 09:44 |
| sean-k-mooney | basicaly i want use to be able to safly dispatch connurent work to a seprate io_thread_pool in our functions and block on the returned future | 09:45 |
| gibi | https://docs.openstack.org/oslo.messaging/latest/reference/executors.html#threading | 09:45 |
| gibi | Executor that uses a thread pool to execute calls asynchronously. | 09:45 |
| sean-k-mooney | yes bvut im not sure if that is just submiting it to rabbit | 09:45 |
| sean-k-mooney | i.e. the read/write calls | 09:46 |
| gibi | I think that is the receiving side | 09:46 |
| gibi | the sending side is simply blocking for cast until rabbit takes the message, and blocking for call until the response arrives | 09:47 |
| sean-k-mooney | so if we get this fro free then cool, this may also be externalise in oslo.service | 09:47 |
| sean-k-mooney | this was on my todo list to look at after the removel of our explict use of eventlet.tpool | 09:48 |
| gibi | yepp executors are for receving messages https://github.com/openstack/oslo.messaging/blob/930d97599c0048e84f7c47dca0d62d2cc0562166/doc/source/reference/executors.rst#L12 | 09:49 |
| sean-k-mooney | https://github.com/openstack/oslo.messaging/blob/930d97599c0048e84f7c47dca0d62d2cc0562166/oslo_messaging/server.py#L368 | 09:49 |
| sean-k-mooney | so ok _on_incomming is just submitting the callback to the executor which in threading mode is a threadpool executor form oslo messaging | 09:50 |
| sean-k-mooney | so this is already done for us | 09:50 |
| gibi | yepp it seems so | 09:50 |
| sean-k-mooney | that is what i was hoping for but as i siad i had not confirmed that till now | 09:50 |
| gibi | btw, as you are around, could you do a review round on the igb series https://review.opendev.org/q/topic:%22bp/igb-vif-model%22 the os-traits part is landed released an bumped into both global and nova reqs. | 09:52 |
| gibi | so the nova series is ready to go | 09:52 |
| sean-k-mooney | oh i was not aware we had approved the bluepirnt yet | 10:51 |
| sean-k-mooney | sure i stood up a devstack yesterday so i can pull it in an try it out and give it a test | 10:51 |
| sean-k-mooney | ill see if i can do that later today | 10:52 |
| gibi | thanks. Yes the bp was approved couple of weeks ago | 10:52 |
| sean-k-mooney | ack i vagule remember that but it didnt click that it was ready for review again | 10:52 |
| sean-k-mooney | for some reasoin i tought we were waiting for the ptg but i was proably thinking about somethign else | 10:53 |
| WJeffs1 | Hey, So I was sure I saw an option once, to run a script locally on the HV after a VM is created and the same for deletion? As I'm being overly hopeful or is this actually an option? | 11:14 |
| sean-k-mooney | not in nova but it is in libvirt | 11:14 |
| sean-k-mooney | libvirt has hooks | 11:14 |
| sean-k-mooney | we dont supprot that but it would allow you to do that | 11:14 |
| WJeffs1 | ahh that was probably where I saw it :) I'll dig there thanks! | 11:14 |
| opendevreview | Stephen Finucane proposed openstack/placement master: requirements: Remove setuptools https://review.opendev.org/c/openstack/placement/+/932398 | 11:50 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/placement/+/932399 | 11:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | 12:56 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Drop dependency on netifaces https://review.opendev.org/c/openstack/nova/+/931582 | 13:10 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | 13:11 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Drop dependency on netifaces https://review.opendev.org/c/openstack/nova/+/931582 | 13:11 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!