| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-15 | |||
| 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 | sean-k-mooney | the problem with a file lock is we want this to actully work if you have mulipel processes | |
| 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: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: Replace utils.spawn_n with spawn https://review.opendev.org/c/openstack/nova/+/948076 | |
| 17:13:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079 | |
| 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:45 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187 | |
| 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: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:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087 | |
| 17:13:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | |
| 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: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: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] | Hey | |
| 18:06:24 | ishanwar[m] | sean-k-mooney (@_oftc_sean-k-mooney:matrix.org) | |
| 18:06:24 | ishanwar[m] | can you have a look for this https://review.opendev.org/c/openstack/nova/+/945204 | |
| 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 | |
| 18:16:24 | JayF | (patches are close to merge that have ironic regen it) | |
| 18:16:54 | sean-k-mooney | JayF: is that to adresss the bonding bug mnaser reported | |
| 18:17:08 | JayF | I think we addressed that in a backportable way | |
| 18:17:26 | cardoe | which is the bug mnaser reported? | |
| 18:18:00 | JayF | https://launchpad.net/bugs/2106073 | |
| 18:18:06 | sean-k-mooney | https://bugs.launchpad.net/ironic/+bug/2106073 | |
| 18:18:13 | sean-k-mooney | :)_ | |
| 18:18:33 | sean-k-mooney | cardoe: its a similar problam statement | |
| 18:19:04 | sean-k-mooney | the config drive is needed to be abel to bootstrap the networkign to be able to hit the metadta when you are usign static ips or bonds | |
| 18:19:37 | sean-k-mooney | specificly any bond that require both the swtich and host to be configured in a given bonding mode for traffic to flow | |
| 18:20:50 | sean-k-mooney | cardoe: your usecase is related but seperate and i think valid | |
| 18:21:10 | sean-k-mooney | cardoe: ironic could enrich the metadat with the turnk port info | |
| 18:21:18 | sean-k-mooney | btu nova can do that too | |
| 18:21:33 | sean-k-mooney | and nova could do it for libvirt or vmware in a generic way | |
| 18:34:24 | cardoe | I would love if neutron modeled this all. Much like I’m trying to get L2 VNI in there. | |
| 18:35:06 | sean-k-mooney | cardoe: when we dicussed trunkports intially we also disucssed bond ports | |
| 18:35:23 | cardoe | Which is something already patched in nova | |
| 18:35:28 | sean-k-mooney | the latter just didnt get doen btu i dont see why you cant have the same bond port sub port relationship | |
| 18:36:06 | sean-k-mooney | port groups in ironci are a littel differnt however then just a bond or turnk port | |
| 18:36:10 | cardoe | Trunk boards are already modeled inside of neutron | |
| 18:36:16 | cardoe | Ports | |
| 18:36:41 | cardoe | It’s nova that doesn’t handle it | |
| 18:37:13 | cardoe | So it’s not really related to that bug. | |
| 18:41:40 | sean-k-mooney | cardoe: so i did a very quick review and asked a few questions but +1 for the over all idea | |
| 18:43:23 | sean-k-mooney | cardoe: im not sure if we currently test turnkprots in the nova ci jobs (maybe the ovs hybrid plug one?) but i know the neutron do and have a tempest plugin to do some more advanced testing with it | |
| 18:43:58 | sean-k-mooney | so whiel im not sure if the trunk connectivty test would be accepted in core tempest it definlly could be done in one of neutron tempest plugins | |
| 18:49:44 | sean-k-mooney | melwitt: speaking of specs are you plannign to work on the vtpm spec and implemetion this cycle. i think that was the plan aroudn the ptg but just touching base to make sure that has not changed? | |
| 18:50:31 | melwitt | argh | |
| 18:50:45 | melwitt | sean-k-mooney: yes I am -- still the plan. I have re-proposed the spec and noted the changes from the last approval in the commit message | |
| 18:51:15 | sean-k-mooney | cool. i will proably try and put aside some time to look at the open spec next week | |
| 18:51:48 | melwitt | sure, thanks | |
| 18:56:03 | melwitt | seen this a few times now, nova-ceph-multistore failures due to "nova.exception.ImageDeleteConflict: Conflict deleting image. Reason: HTTP 409 Conflict: Image a34561ed-6ef7-457c-8845-677f83af10de could not be deleted because it is in use: The image cannot be deleted because it is in use through the backend store outside of Glance.." | |
| 18:56:54 | sean-k-mooney | ya | |
| 18:56:57 | sean-k-mooney | i noticed that too | |
| 18:57:22 | melwitt | I wonder if anything's changed or why it's happening often recently. I haven't spent time looking into it yet | |
| 19:10:55 | cardoe | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/941227 is the implementation. Linked you’ll find the addition of tests and tempest patches as well to test it all. | |
| 19:32:13 | sean-k-mooney | cardoe: can you put the implemation and the spec on a gerrit topic called bp/<sepc/blueprint name> | |