| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-15 | |||
| 10:11:43 | opendevreview | Serhii Ivanov proposed openstack/nova-specs master: Proposes 'Add Graceful Nova Compute Shutdown' https://review.opendev.org/c/openstack/nova-specs/+/937185 | |
| 10:14:40 | opendevreview | Serhii Ivanov proposed openstack/nova-specs master: Proposes 'Add Graceful Nova Compute Shutdown' https://review.opendev.org/c/openstack/nova-specs/+/937185 | |
| 10:16:17 | opendevreview | Ivan Anfimov proposed openstack/placement master: wip https://review.opendev.org/c/openstack/placement/+/949864 | |
| 10:17:16 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove installation guide for openSUSE/SLES https://review.opendev.org/c/openstack/placement/+/949864 | |
| 10:38:03 | opendevreview | Ivan Anfimov proposed openstack/nova master: wip https://review.opendev.org/c/openstack/nova/+/945781 | |
| 11:58:46 | opendevreview | Lajos Katona proposed openstack/os-vif master: VS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/949736 | |
| 12:46:10 | opendevreview | Merged openstack/nova master: Amend functional reproducer for bug 1899835 https://review.opendev.org/c/openstack/nova/+/946581 | |
| 13:50:36 | MengyangZhang[m]1 | Hi folks,... (full message at <https://matrix.org/oftc/media/v1/media/download/AQCeKS0ygNQmR5GAVx8_xminTOY9XUuccxdyP6UnUQrmb3Vz1w1JBUlNsmlKKGyklGrLpna6pA6u3Ut2PN1dGyJCeXHE8e3wAG1hdHJpeC5vcmcvdnJhVFZrZ1hHbERzQWJWVFluSVJ0bE5s>) | |
| 16:43:22 | gibi | stephenfin: sean-k-mooney: melwitt: I think we indeed have a useless lock in https://review.opendev.org/c/openstack/nova/+/949161/comment/e72e2ca3_b8b7f24f/ | |
| 16:44:34 | sean-k-mooney | gibi: so this was there i belvie because of mod_wsig | |
| 16:45:01 | sean-k-mooney | but i guess your right that becasue we reinitalise the lock | |
| 16:45:31 | sean-k-mooney | even if its reloaded it wont guard the we we expect | |
| 16:45:39 | gibi | yeah | |
| 16:45:58 | melwitt | hm | |
| 16:45:58 | sean-k-mooney | we need either only create the lock if it is not None or delete it | |
| 16:46:49 | gibi | I think there is no way to threadsafely check if the variable is None and set it atomically | |
| 16:47:00 | sean-k-mooney | if we really want we coudl proably apply the run once decorator to init_applciation | |
| 16:47:01 | gibi | at least not in this context | |
| 16:47:54 | sean-k-mooney | what we are trying to do is not have 2 thread reintiallse the applction object | |
| 16:48:25 | gibi | we would need to guard the is None check with a lock :) | |
| 16:48:45 | sean-k-mooney | on the other hand nova does nto currently supprot using multiple thread in mod_wsgi any way for other reasons | |
| 16:49:09 | sean-k-mooney | gibi: you normlly fix this with atomics | |
| 16:49:20 | gibi | yeah CAS | |
| 16:49:25 | gibi | which we don't have :) | |
| 16:49:34 | sean-k-mooney | well actully | |
| 16:49:38 | sean-k-mooney | how we fix it in nova | |
| 16:49:45 | sean-k-mooney | is we use the synconise decorator | |
| 16:49:53 | sean-k-mooney | to create a filesystem level lock | |
| 16:51:12 | melwitt | with the guard you would just check None once outside the lock and again inside the lock before proceeding to init, no? | |
| 16:51:52 | sean-k-mooney | you mean double check locking that only works if you declari the loc with static lifetime | |
| 16:52:17 | melwitt | right | |
| 16:52:21 | gibi | the lock needs to exists before any of the two threads enters, otherwise both can create a lock as both can see that the lock variable is none | |
| 16:52:42 | sean-k-mooney | so we can test this if we just import the module twice in an inteperer | |
| 16:53:30 | gibi | to trigger the race the thread needs to be switched right after the first thread checked that the lock is none but before set the lock variable | |
| 16:53:37 | gibi | so it is not easy to trigger the actual race | |
| 16:54:19 | sean-k-mooney | oh becase of the if applcation is None | |
| 16:54:47 | sean-k-mooney | melwitt: right if we use a file lock or any interprocess lock form oslo utils | |
| 16:55:21 | melwitt | yeah. seems like one of those is consistent with other stuff in nova | |
| 16:55:24 | sean-k-mooney | then the filesytem will ensure a strict orderign for us and the handle is just that | |
| 16:55:52 | gibi | yeah external lock works, if we can create them before any of the threads enter, we cannot let the threads create the lock after they checking for none, as the none check would be unprotected | |
| 16:56:28 | melwitt | we already @run_once for the global data init. I guess we could just move it? dunno | |
| 16:56:34 | sean-k-mooney | we can add a do_init function the the curent logic and decorate that | |
| 16:57:36 | gibi | I think either the module import (and therefore the module level code execution) already happens under a lock or we cannot make this thread safe. | |
| 16:57:36 | sean-k-mooney | the problem with a file lock is we want this to actully work if you have mulipel processes | |
| 16:57:56 | sean-k-mooney | so the name has to include the pid the trehad is form | |
| 16:58:52 | gibi | yepp there is an import lock... | |
| 16:59:10 | sean-k-mooney | gibi: well there is also the gil | |
| 16:59:18 | sean-k-mooney | but we doen really want to rely on that | |
| 17:00:04 | gibi | I don't see who can you create a lock in the module level code that is threadsafe and ensured to be only created once | |
| 17:00:10 | gibi | a/who/how/ | |
| 17:00:57 | gibi | if lock not is None: lock = createLock() # is not thread safe | |
| 17:01:40 | gibi | it is only threadsafe as there is an explicit import lock in python so we know that the module level code only run by a single thread uninterupted | |
| 17:02:04 | gibi | but with that we can have just an applicaton is None check, no need to any other locks | |
| 17:12:11 | gibi | https://docs.python.org/fr/3.8/library/imp.html#imp.lock_held | |
| 17:13:43 | opendevreview | Balazs Gibizer proposed openstack/nova master: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/948072 | |
| 17:13:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079 | |
| 17:13:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Replace utils.spawn_n with spawn https://review.opendev.org/c/openstack/nova/+/948076 | |
| 17:13:45 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187 | |
| 17:13:45 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move ComputeManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948186 | |
| 17:13:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename DEFAULT_GREEN_POOL to DEFAULT_EXECUTOR https://review.opendev.org/c/openstack/nova/+/948086 | |
| 17:13:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make nova.utils.pass_context private https://review.opendev.org/c/openstack/nova/+/948188 | |
| 17:13:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | |
| 17:13:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087 | |
| 17:13:49 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP: allow service to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | |
| 17:13:49 | opendevreview | Balazs Gibizer proposed openstack/nova master: Document threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | |
| 17:13:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | |
| 17:52:47 | cardoe | hey all. I see you don't have https://review.opendev.org/c/openstack/nova-specs/+/471815 on your roadmap for 2025.2 | |
| 17:52:52 | cardoe | Any chance we can get that added? | |
| 17:53:10 | cardoe | There's a number of operators that are using Ironic with Nova and need trunk port data. | |
| 17:53:55 | cardoe | The actual implementation of that was proposed by two different companies against nova. | |
| 17:54:15 | cardoe | I've gotten everyone to collapse down behind Vasyl's patch and he's updated the spec as asked. | |
| 17:55:17 | cardoe | There's a push on doing this on the Ironic side as well for some standalone cases. | |
| 17:55:40 | cardoe | Really wanting to advocate for collaboration here between the projects and to fulfill operator need. | |
| 17:55:47 | cardoe | We're essentially blocked on reviews. | |
| 18:06:24 | ishanwar[m] | can you have a look for this https://review.opendev.org/c/openstack/nova/+/945204 | |
| 18:06:24 | ishanwar[m] | sean-k-mooney (@_oftc_sean-k-mooney:matrix.org) | |
| 18:06:24 | ishanwar[m] | Hey | |
| 18:07:20 | sean-k-mooney | cardoe: is that the vnc console one | |
| 18:07:25 | sean-k-mooney | to provide a graphical console | |
| 18:07:52 | cardoe | No. That's trunk port info in metadata | |
| 18:07:54 | sean-k-mooney | cardoe: oh its not | |
| 18:08:12 | sean-k-mooney | cardoe: so that problemantic | |
| 18:08:42 | sean-k-mooney | cardoe: the problem is tha twhen ironci is used vai nova it relaly should not be touchign the neutorn prots at all | |
| 18:09:11 | sean-k-mooney | cardoe: which means that to supprot port group and trunkign it shoudl be modeled in neutron | |
| 18:09:15 | sean-k-mooney | whic hits not today | |
| 18:10:12 | cardoe | I don't disagree. | |
| 18:10:24 | cardoe | One of the many specs on my queue to write. | |
| 18:11:29 | sean-k-mooney | cardoe: without deep diving into the spec we probably can supprot addign the subport info into the metadtata api or config drive | |
| 18:11:37 | sean-k-mooney | for any virt dirver | |
| 18:11:40 | sean-k-mooney | even ironic | |
| 18:11:58 | sean-k-mooney | but only if the trunk port is pass by uuid as part of the boot request | |
| 18:12:23 | sean-k-mooney | if ironic makes changes to the prots out of band however | |
| 18:12:45 | sean-k-mooney | i.e. maping that 1 neutorn trunk port to to a port group | |
| 18:12:57 | sean-k-mooney | your kind of out of luck | |
| 18:13:50 | sean-k-mooney | so like you could not really combin doign bondign via port groups and this | |
| 18:14:54 | JayF | Yeah, that's been the root pain the whole time. To model this all in network metadata on the nova side requires it to be modeled all the way through, which I think has to start with neutron not with nova | |
| 18:15:14 | sean-k-mooney | cardoe: or rather if you did try and combind them nova can only provide the info it had ebfore we call ironci to provision in the config drive | |
| 18:15:50 | sean-k-mooney | JayF:right we can add any info that is aviabel from neutron at the point we generate the config drive | |
| 18:16:07 | sean-k-mooney | but after that point either ironic need to update it itsself | |
| 18:16:16 | sean-k-mooney | or we would need a way to trigger a refresh | |