| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-15 | |||
| 09:39:18 | 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:40:21 | sean-k-mooney | thats a good question. This query_wrapper function is only used in one place i belive | |
| 09:40:31 | sean-k-mooney | im not sure if we have this patterin in ohter however | |
| 09:41:14 | sean-k-mooney | im currently trying to play with creating a BoundTask class to do that | |
| 09:41:38 | sean-k-mooney | maybe TimerTask naming is hard | |
| 09:41:40 | gibi | I guess we have timers in the compute for e.g. vif_plug events | |
| 09:42:15 | sean-k-mooney | yes but it depend on how they are used | |
| 09:42:33 | sean-k-mooney | what i want to do and other can disagree | |
| 09:42:51 | sean-k-mooney | is have our main loop handel pooling for RPC messages | |
| 09:43:02 | sean-k-mooney | but dispatch the message handler to a worker thread pool | |
| 09:43:36 | sean-k-mooney | so basiclaly each RPC handlelr woudl be spawned into its own thread which it can freely block on | |
| 09:43:46 | 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:44:09 | sean-k-mooney | ya im kind fo hoping it does but not sure either | |
| 09:45:12 | 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:21 | gibi | https://docs.openstack.org/oslo.messaging/latest/reference/executors.html#threading | |
| 09:45:26 | gibi | Executor that uses a thread pool to execute calls asynchronously. | |
| 09:45:51 | sean-k-mooney | yes bvut im not sure if that is just submiting it to rabbit | |
| 09:46:23 | sean-k-mooney | i.e. the read/write calls | |
| 09:46:28 | gibi | I think that is the receiving side | |
| 09:47:01 | gibi | the sending side is simply blocking for cast until rabbit takes the message, and blocking for call until the response arrives | |
| 09:47:57 | sean-k-mooney | so if we get this fro free then cool, this may also be externalise in oslo.service | |
| 09:48:18 | sean-k-mooney | this was on my todo list to look at after the removel of our explict use of eventlet.tpool | |
| 09:49:35 | gibi | yepp executors are for receving messages https://github.com/openstack/oslo.messaging/blob/930d97599c0048e84f7c47dca0d62d2cc0562166/doc/source/reference/executors.rst#L12 | |
| 09:49:41 | sean-k-mooney | https://github.com/openstack/oslo.messaging/blob/930d97599c0048e84f7c47dca0d62d2cc0562166/oslo_messaging/server.py#L368 | |
| 09:50:29 | 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:37 | sean-k-mooney | so this is already done for us | |
| 09:50:53 | sean-k-mooney | that is what i was hoping for but as i siad i had not confirmed that till now | |
| 09:50:53 | gibi | yepp it seems so | |
| 09:52:14 | 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:37 | gibi | so the nova series is ready to go | |
| 10:51:30 | sean-k-mooney | oh i was not aware we had approved the bluepirnt yet | |
| 10:51:58 | 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:52:19 | sean-k-mooney | ill see if i can do that later today | |
| 10:52:33 | gibi | thanks. Yes the bp was approved couple of weeks ago | |
| 10:52:58 | sean-k-mooney | ack i vagule remember that but it didnt click that it was ready for review again | |
| 10:53:32 | sean-k-mooney | for some reasoin i tought we were waiting for the ptg but i was proably thinking about somethign else | |
| 11:14:07 | 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:26 | sean-k-mooney | not in nova but it is in libvirt | |
| 11:14:30 | sean-k-mooney | libvirt has hooks | |
| 11:14:40 | sean-k-mooney | we dont supprot that but it would allow you to do that | |
| 11:14:50 | WJeffs1 | ahh that was probably where I saw it :) I'll dig there thanks! | |
| 11:50:03 | opendevreview | Stephen Finucane proposed openstack/placement master: requirements: Remove setuptools https://review.opendev.org/c/openstack/placement/+/932398 | |
| 11:50:04 | opendevreview | Stephen Finucane proposed openstack/placement master: Add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/placement/+/932399 | |
| 12:56:33 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | |
| 13:10:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop dependency on netifaces https://review.opendev.org/c/openstack/nova/+/931582 | |
| 13:11:42 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | |
| 13:11:47 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop dependency on netifaces https://review.opendev.org/c/openstack/nova/+/931582 | |
| 13:44:55 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop dependency on netifaces https://review.opendev.org/c/openstack/nova/+/931582 | |
| 13:45:20 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | |
| 13:45:27 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407 | |
| 16:02:25 | bauzas | doh | |
| 16:02:33 | bauzas | I was using the wrong chan (-tc) | |
| 16:03:01 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:03:01 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:03:01 | opendevmeet | Meeting started Tue Oct 15 16:03:01 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:03:01 | bauzas | #startmeeting nova | |
| 16:03:06 | tkajinam | :-) | |
| 16:03:13 | bauzas | hey folks, this time I'm on the right channel :) | |
| 16:03:18 | tkajinam | o/ | |
| 16:03:20 | elodilles | o/ | |
| 16:03:28 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:03:37 | bauzas | I was wondering why I was getting crickets :) | |
| 16:04:09 | bauzas | so, who's around ? | |
| 16:04:26 | Uggla | o/ | |
| 16:05:16 | bauzas | okay, we can softly start | |
| 16:05:23 | bauzas | #topic Bugs (stuck/critical) | |
| 16:05:29 | bauzas | #info One Critical bug | |
| 16:05:34 | bauzas | #link https://bugs.launchpad.net/nova/+bug/2083518 | |
| 16:05:40 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:05:40 | fwiesel | o/ | |
| 16:05:58 | bauzas | I'm considering to change the priority of the critical bug to High | |
| 16:06:01 | tkajinam | I downgraded the importance of it as I learned that distutils may be available via setuptools (IIUC) | |
| 16:06:20 | bauzas | oh thanks, all good then | |
| 16:06:24 | tkajinam | However as it is deprecated we definitely need an alternative. As recent python more actively drops things | |
| 16:06:45 | bauzas | we'll have py312 jobs that should see that | |
| 16:06:49 | tkajinam | I started adding something to oslo.utils to replace distutils now and may ping you once that becomes available | |
| 16:06:50 | tkajinam | yeah | |
| 16:07:09 | tkajinam | the tricky thing is that it may not appear as long as we use virtualenv | |
| 16:07:17 | tkajinam | but it appears if you do python -m venv | |
| 16:07:20 | tkajinam | iiuc | |
| 16:07:23 | bauzas | oh, okay, so tox wouldn't see it | |
| 16:07:32 | tkajinam | yup | |
| 16:07:35 | bauzas | and our jobs too, hence why this is not failing in the jobs | |
| 16:07:53 | bauzas | because I guess the tox embedded python version has distutils ? | |
| 16:08:06 | bauzas | s/tox/venv | |
| 16:08:10 | sean-k-mooney | distutils is installable | |
| 16:08:15 | sean-k-mooney | on py312 | |
| 16:08:18 | sean-k-mooney | as a sperate package | |
| 16:08:20 | tkajinam | no but it installs setuptools which brings distutils and pkg_resources | |
| 16:08:37 | tkajinam | but these were kicked out from core python in 3.12 | |
| 16:08:40 | sean-k-mooney | but i belive that is not the case on 3.13 | |
| 16:09:07 | tkajinam | +1 | |
| 16:10:13 | bauzas | so we need to remove that dep from our code | |
| 16:10:24 | sean-k-mooney | https://packages.ubuntu.com/noble/python3-distutils-extra | |
| 16:10:24 | bauzas | I'm just sad we don't have any canary in the coal mine | |
| 16:10:31 | sean-k-mooney | yes eventualy | |
| 16:10:42 | sean-k-mooney | sooner rather then later which is why tkajinam started on it | |
| 16:10:59 | tkajinam | yes :-) | |
| 16:11:10 | sean-k-mooney | our acutal deps on it are somewhat limisted | |
| 16:11:47 | sean-k-mooney | but that is not the same as 0 | |