| *** mhen_ is now known as mhen | 01:40 | |
| cardoe | Hey all. I've brought this spec up before and folks have said they're good with it. There's a number of operators that are patching the nova code with patches to achieve this. I'm trying to advocate for these downstream operators to engage more with upstream OpenStack projects with my TC member hat on. https://review.opendev.org/c/openstack/nova-specs/+/471815 | 02:56 |
|---|---|---|
| cardoe | We're now seeing associated projects (neutron) marking the patches as abandoned because they don't believe it'll go anywhere. | 02:56 |
| cardoe | Please help me folks. | 02:57 |
| jkulik | NicolaiRuckel: sounds to me like you're using system_metadata in your patches, but the object doesn't have that loaded - and can't load it later on. system_metadata would have to get queried out (or set, since we're talking about tests) when the Instance is fetched from the DB/created in the tests. | 06:17 |
| opendevreview | Stephen Finucane proposed openstack/nova master: tests: Replace keystoneclient with keystoneauth1 https://review.opendev.org/c/openstack/nova/+/951744 | 09:27 |
| NicolaiRuckel | jkulik: The weird thing is that I didn't knowingly touch system_metadata at all. | 09:27 |
| jkulik | NicolaiRuckel: then maybe your patch calls some function that does consume it? little hard to tell ;) | 09:42 |
| NicolaiRuckel | What surprised me is that the tests (for example functional.libvirt.test_uefi:test_create_server) always had the assertion `self.assertIn('image_hw_machine_type', instance.system_metadata)` and used to pass but somehow I managed to make it not lazy-loadable anymore. Is there any documentation on how system_metadata gets set/defined? | 09:52 |
| jkulik | afaik, there's just code. | 09:53 |
| NicolaiRuckel | I was afraid that this would be the answer. :D | 09:54 |
| jssfr | NicolaiRuckel, maybe you can link / paste the specific patch you're looking at? | 09:54 |
| NicolaiRuckel | one second, I need to make the repository public first | 09:59 |
| NicolaiRuckel | This seems to be the commit that breaks the test: https://gitlab.com/NicolaiRuckel/nova/-/commit/9d6e6f44d5129a9de3c7f4a636e82411a711e3e3 | 10:05 |
| jkulik | Your use of `objects.Intance` looks weird. If I understand it right, you're assigning the `uuid` to the class - not an individual Instance instance. Maybe that breaks stuff. | 10:15 |
| NicolaiRuckel | That sounds reasonable. I'll look into that. Thanks! | 10:31 |
| darkhackernc | https://bugs.launchpad.net/nova/+bug/2119126 team can someone look into this | 11:24 |
| mohsen__ | hello everyone. I have an issue with resource tracking in openstack. | 11:32 |
| mohsen__ | I have set the following configs in my nova compute nova.conf file: | 11:32 |
| mohsen__ | [compute] | 11:32 |
| mohsen__ | cpu_shared_set = 0-17,36-53 | 11:32 |
| mohsen__ | cpu_dedicated_set = 18-35,54-71 | 11:32 |
| mohsen__ | and I enabled the NUMATopologyFilter and AggregateInstanceExtraSpecsFilter filters so that I can schedule cpu-pinned instances on my desired aggregate of compute hosts. | 11:32 |
| mohsen__ | The issue is that the placement service periodically adds the specified set of dedicated cpus to the inventory as PCPU section, and after a while, it removes the PCPU section of the inventory unexpectedly. which results to not being able to delete instances and getting the following error: | 11:32 |
| mohsen__ | Error during ComputeManager.update_available_resource: nova.exception.ReshapeNeeded: Virt driver indicates that provider inventories need to be moved. | 11:32 |
| mohsen__ | I appreciate your ideas in advance | 11:32 |
| sean-k-mooney | mohsen__: is this an existign deployment with workload? | 11:57 |
| sean-k-mooney | modifyign the legacy vcpu_pin_set and newer cpu_*_sets shoudl only be done on empty hosts | 11:57 |
| sean-k-mooney | im not aware of a bug that would cause the issue you describe but it sound like the "reshape" code that is run when upgrading to a release that supprot pinned and unpined guests on the same host is trying to fix the allocations/inventories. i dont know what woudl cause the pcpu invetoies to be removed other hten perhaps if the resouce tracker was broken by vms running on the | 12:00 |
| sean-k-mooney | wrong cores. that can happen if you defiend or modifed those values when vms were on the hosts | 12:00 |
| sean-k-mooney | darkhackernc: if the compute service is down the instance is not expected to be manageable via the nova api | 12:02 |
| mohsen__ | sean-k-mooney: Yes. My OpenStack environment already has a couple of instances up and running on it. | 12:06 |
| mohsen__ | Thank you for your helpful response | 12:06 |
| sean-k-mooney | darkhackernc: this looks like a masikari issue so i marked the bug as invliad for nova. | 12:13 |
| NicolaiRuckel | jkulik: That really helped. I was able to fix the problem now. | 12:26 |
| jkulik | NicolaiRuckel: nice! | 12:31 |
| opendevreview | Lajos Katona proposed openstack/nova master: WIP Use SDK for Neutron https://review.opendev.org/c/openstack/nova/+/928022 | 12:36 |
| mohsen__ | sean-k-mooney: I migrated all the instances from one compute node to another computes. then reconfigured nova with the mentioned config above on the compute host where there aren't any instances no longer. then I ran "openstack resource provider inventory list <compute-host-uuid>" command and find out that the same issue still exists. what could be the root cause? | 13:09 |
| sean-k-mooney | mohsen__: you have restared the compute agent on the host since it was drained? | 13:10 |
| mohsen__ | sean-k-mooney: since I used kolla-ansible to reconfigure it, it has a handler which do the restart task after modification. I didn't do it manually but I can test it. | 13:11 |
| sean-k-mooney | if so and the issue still happens i think your going to have to file a bug with some logs. i.e. the full error message or warning form the reouce tracker and or perodic task related to the createion or update of the resouce provider | 13:12 |
| sean-k-mooney | mohsen__: you did the reconfiugre while there were isntances on the host correct | 13:12 |
| sean-k-mooney | have you restarted it since it was empty | 13:12 |
| mohsen__ | sean-k-mooney: I evacuated all the instances and then ran the kolla-ansible to reconfigure it. the restart task had been run after all the instances were evacuated. | 13:14 |
| mohsen__ | sean-k-mooney: After evacuating all the instances and after reconfiguration, I manually restarted it and the issue still persist. sounds like there is no way unless reporting a bug🤔 | 13:18 |
| sean-k-mooney | ack, without inspecigng the logs and or error i cant really advise more. i likely wont have time to dig much deeper in the short term unfortunetly. i woudl suggeset filing a bug and trying to extract any relevent log messages (ideally at debug level) that are related to teh execution of the update_aviable_resouce provider perodic and the intiall startup of the agent related to | 13:18 |
| sean-k-mooney | when it initally created teh RP invetories with the PCPUs inventory. you mentioned it initally was created and then lost correct? it would be good to try and capture the relevent logs showing both | 13:18 |
| mohsen__ | sean-k-mooney: Thank you for your guidance | 13:21 |
| *** ykarel_ is now known as ykarel | 14:01 | |
| cardoe | I know the nova meeting is coming up and I just want to ping on https://review.opendev.org/c/openstack/nova-specs/+/471815 I pinged earlier. | 14:58 |
| Uggla | Nova meeting in ~30mn | 15:30 |
| Uggla | #startmeeting nova | 16:01 |
| opendevmeet | Meeting started Tue Aug 5 16:01:39 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| Uggla | Hello everyone | 16:01 |
| jssfr | o/ | 16:02 |
| jssfr | NicolaiRuckel and me would like to bring up a topic in the "Open Discussion" slot | 16:02 |
| jssfr | (jfyi) | 16:02 |
| fwiesel | o/ | 16:02 |
| Uggla | jssfr, no pb but this week few people are available. | 16:02 |
| jssfr | thanks for the heads up :) | 16:03 |
| gmaan | o/ | 16:03 |
| Uggla | awaiting people to join, but I'm pretty sure we will not have quorum. | 16:04 |
| Uggla | Please raise your hand for showing you are part of the meeting. | 16:04 |
| NicolaiRuckel | o/ | 16:05 |
| dansmith | o/ | 16:05 |
| Uggla | Let's start | 16:06 |
| Uggla | #topic Bugs (stuck/critical) | 16:06 |
| Uggla | #info No Critical bug | 16:06 |
| melwitt | o/ | 16:06 |
| Uggla | #topic Gate status | 16:07 |
| Uggla | hey melwitt, good to see you | 16:07 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:07 |
| Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:07 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:07 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:07 |
| Uggla | #info Gate was blocked last week with "openstack.exceptions.SDKException: Image creation failed: 'latin-1' codec can't encode character '\u2019' in position 662: ordinal not in range(256) in openstack.tests.functional.image.v2.test_image.TestImage.test_tags". | 16:08 |
| Uggla | #info https://review.opendev.org/c/openstack/openstacksdk/+/956369 fixed it | 16:08 |
| Uggla | #topic tempest-with-latest-microversion job status | 16:08 |
| Uggla | #link https://zuul.opendev.org/t/openstack/builds?job_name=tempest-with-latest-microversion&skip=0 | 16:08 |
| Uggla | gmaan, do you have something to share ? | 16:09 |
| gmaan | ah, no update on this. | 16:10 |
| Uggla | thanks, so moving on | 16:10 |
| Uggla | #topic Release Planning | 16:10 |
| Uggla | #link https://releases.openstack.org/flamingo/schedule.html | 16:11 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:11 |
| Uggla | Time is flying, a bit less than 4 weeks before FF. | 16:12 |
| Uggla | #topic Review priorities | 16:12 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | 16:12 |
| Uggla | I guess the file is updated, please let me know if something is wrong in it. | 16:13 |
| Uggla | #topic OpenAPI | 16:13 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:13 |
| Uggla | #info up from 13 to 32 remaining. (I guess Stephen created new ones and follow up) | 16:13 |
| Uggla | I hope we can see an end about this. | 16:14 |
| Uggla | I'm going to skip stable branch topic because Elod is on pto. | 16:15 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:15 |
| Uggla | fwiesel, something on our side ? | 16:15 |
| fwiesel | #info fwiesel will be on PTO until the 9/9 | 16:15 |
| fwiesel | Otherwise, no news from me. | 16:15 |
| fwiesel | Uggla: back to you | 16:16 |
| Uggla | fwiesel, I wish you'll enjoy your PTO. | 16:16 |
| fwiesel | Thanks! | 16:16 |
| Uggla | Also skiping Gibi's point about eventlet removal due to Gibi's well deserved pto. | 16:17 |
| Uggla | #topic Open discussion | 16:17 |
| melwitt | I have a small topic | 16:18 |
| Uggla | So jssfr, giving the mic to you. | 16:18 |
| jssfr | thanks! | 16:18 |
| jssfr | so we're currently looking into two topics which are somewhat related: | 16:18 |
| jssfr | first we're rebasing https://review.opendev.org/c/openstack/nova/+/621646 | 16:18 |
| jssfr | second I proposed a draft patch for a vTPM data preservation issue a couple weeks ago: https://review.opendev.org/c/openstack/nova/+/955657 | 16:18 |
| sean-k-mooney | o/ sorry was doign something else | 16:19 |
| jssfr | o/ | 16:19 |
| jssfr | I also think that sean-k-mooney proposed something similar to the vTPM draft for UEFI NVRAM preservation | 16:19 |
| jssfr | we'd like to hear whether we're heading the right direction by rebasing #621646 regarding UEFI, or whether there might be a better way. | 16:20 |
| sean-k-mooney | i was suggeing bring it up in this meetign yes | 16:20 |
| melwitt | oh, good. this was the topic I wanted heh (vTPM data) | 16:20 |
| sean-k-mooney | or rather that melwitt bring it up | 16:20 |
| jssfr | I also saw only now that you replied to #955657, because I had my inbox sorting messed up, reading that now. | 16:20 |
| sean-k-mooney | melwitt: do you want to summerize | 16:21 |
| jssfr | read it | 16:21 |
| melwitt | sure | 16:21 |
| melwitt | we are looking for input and consensus about handling the recently raised issue in the community regarding vTPM data that is lost across guest reboots https://bugs.launchpad.net/nova/+bug/2118888 and https://review.opendev.org/c/openstack/nova/+/955657 the tl;dr is that this is a latent problem that originates in libvirt | 16:21 |
| melwitt | libvirt added a flag for this VIR_DOMAIN_UNDEFINE_KEEP_TPM a couple of years after vTPM was added in Nova and jssfr has proposed a patch for using the flag ^ | 16:22 |
| jssfr | (which will need a bit of work, such as adding tests) | 16:22 |
| jssfr | (but I can do that) | 16:22 |
| sean-k-mooney | there is a related but seperate issue that related to the nvram data | 16:22 |
| sean-k-mooney | again there are now flag to supprot keeping or removing the nvram file | 16:23 |
| jssfr | (UEFI NVRAM bug is https://bugs.launchpad.net/nova/+bug/1785123, patch-with-merge-conflicts is https://review.opendev.org/c/openstack/nova/+/621646 ) | 16:23 |
| dansmith | so if we do that, we need to do our own deleting of the TPM file when we undefine to actually delete the instance? | 16:23 |
| jssfr | dansmith, no, because we can just not pass that flag when we truly want to delete | 16:23 |
| sean-k-mooney | dansmith: no. we can pass the keep or delte flag as approtiate | 16:23 |
| jssfr | in my draft patch, I tied it to the delete_storage bool IIRC | 16:23 |
| dansmith | oh it's a flag _to_ undefine? | 16:24 |
| jssfr | yes :) | 16:24 |
| melwitt | yes | 16:24 |
| dansmith | okay | 16:24 |
| dansmith | ah I see yes, okay | 16:24 |
| sean-k-mooney | so we have a number of placess we undefine the vm today wher the data shoudl not be deleted, hard-reboot is one but also some volume operations require use to temporlly undefien the domain | 16:24 |
| melwitt | we are thinking about, how to fix this for older versions. the flag addition could be technically seen as a "feature" but IMHO the impact is quite significant and personally I would think about backporting the flag fix to older versions that could be reasonably expected to use libvirt >= 8.9.0 where the flag was introduced | 16:25 |
| melwitt | wondering what others think of this | 16:26 |
| dansmith | shifting behaviors in a library that we have to account for is not a feature, IMHO | 16:26 |
| jssfr | I think a backport would be quite appropriate | 16:26 |
| jssfr | and we are going to backport to at least 2024.1 anyway | 16:26 |
| jssfr | so we could contribute those backported patches at least. | 16:27 |
| sean-k-mooney | dansmith: the wrinkel is libvirt uncondtionally delete the data when we added vtpm supprot and the option to preseve it was added 2 years later | 16:27 |
| dansmith | yeah understand | 16:27 |
| sean-k-mooney | with that said the didnt really document that which is partly why we missed it but i agre we shoudl not require a feature to "do the write thign" | 16:28 |
| jssfr | sean-k-mooney, so you're saying it's not shifting behaviour in libvirt, but simply a bug which existed since forever but which nobody noticed? | 16:28 |
| sean-k-mooney | jssfr: yes, however that does not mean i belive we shoudl consider it a feature | 16:28 |
| sean-k-mooney | i supprot the idea of fixing this condtional on the libvirt verison | 16:28 |
| dansmith | it's shifting behavior and our failure to account for it is a bug not a feature | 16:28 |
| jssfr | (I get the impression that "feature" versus "bug" is an important distinction here, but I'm not sure why. backporting/support policies?) | 16:28 |
| sean-k-mooney | and possibel backporting that based on dicusssion with teh stable team | 16:29 |
| melwitt | I agree with dansmith | 16:29 |
| sean-k-mooney | dansmith: well the default never changed in libvirt. it still deleted on undefine by defualt. they just added the ablity to keep it in later release | 16:29 |
| sean-k-mooney | so do we agree to treat this a logic bug in nova | 16:29 |
| sean-k-mooney | i.e. that we didnt account for how this actully works | 16:30 |
| sean-k-mooney | and if so are we ok with usign the flags to adress that | 16:30 |
| sean-k-mooney | jssfr: yes the stable plociy does not allow feature backports upstream | 16:30 |
| jssfr | aha, thanks! | 16:31 |
| sean-k-mooney | jssfr: there are very limited excptions to that | 16:31 |
| jssfr | noted, thanks. | 16:31 |
| melwitt | I support backporting use of the flags (with libvirt version conditional) | 16:32 |
| sean-k-mooney | im +1 on treating it as a but and fixing it by approatbly passing the flags to undefine based on if we are deleting the instance or just undefining for some other reason | 16:32 |
| NicolaiRuckel | this applies to both vTPM and UEFI, right? | 16:33 |
| sean-k-mooney | s/as a but/as a bug/ | 16:33 |
| sean-k-mooney | so its the same patther and the same logic bug | 16:33 |
| sean-k-mooney | so i think we could apply the same direction to both | 16:34 |
| melwitt | +1 | 16:34 |
| jssfr | sean-k-mooney, does this only apply for the accidental deletion on undefine for UEFI, or also for the loss of NVRAM data during migrations? | 16:34 |
| sean-k-mooney | the specific libvirt verions may differ for the relevent flags | 16:34 |
| sean-k-mooney | so we shoudl fix both as seperate patches | 16:34 |
| sean-k-mooney | jssfr: nvram data is actully copied during live migration i belive | 16:35 |
| sean-k-mooney | cold migration is sperate. we shoudl focus on the non move operations cases first | 16:35 |
| jssfr | NicolaiRuckel, any evidence of nvram preservation during live migrations when initially rebased https://review.opendev.org/c/openstack/nova/+/621646 ? | 16:36 |
| sean-k-mooney | im not sure which subset of opertions loose nvram data but fixing all fo them is not going to be a singel bug | 16:36 |
| jssfr | understood, thanks. | 16:36 |
| sean-k-mooney | jssfr: i belive its copied by qemu | 16:36 |
| jssfr | aha | 16:36 |
| jssfr | NicolaiRuckel, we'll have to double-check that in the devstack, without the rebased patches. | 16:37 |
| NicolaiRuckel | yeah, I didn't try it yet | 16:37 |
| NicolaiRuckel | There were so many failing test cases that I wanted to clean that up first. | 16:37 |
| sean-k-mooney | i would sugget fixign one bug first then the other | 16:38 |
| sean-k-mooney | i dont really have a prefence in order but proably vtpm might be less work | 16:38 |
| sean-k-mooney | for nvram there is existing tech debt that need to be unwornd related to rebuild | 16:38 |
| jssfr | sean-k-mooney, okay, I'll get to work on making the vTPM patch ready for merge this week then. | 16:38 |
| jssfr | probably not going to *finish* it this week though. What is the time we need to submit the polished patch (incl. tests) for it to be realistically merged for Flamingo? | 16:39 |
| sean-k-mooney | you have about 3 weeks | 16:39 |
| jssfr | okay, so 1w before FF | 16:39 |
| jssfr | noted | 16:39 |
| sean-k-mooney | well you have until FF | 16:40 |
| jssfr | oh I thought that was in 4 weeks. | 16:40 |
| Uggla | A bit less than 4 weeks | 16:40 |
| jssfr | right | 16:40 |
| sean-k-mooney | after which it woudl need a backport but its not a regressin intoduced in this cycle so between FF and RC1 we dont fix a lot of latent bugs | 16:40 |
| sean-k-mooney | after rc 1 is cut the branch woudl be reopen for bugfixes again | 16:40 |
| Uggla | FF will be August 28th | 16:41 |
| jssfr | it should be doable to finish it in two weeks, so I'll aim for a submission before or on 2025-08-19 | 16:41 |
| sean-k-mooney | yep that why i said about 3 weeks | 16:41 |
| NicolaiRuckel | I'll continue with rebasing/fixing the UEFI patch in the meantime. | 16:41 |
| sean-k-mooney | i think we can move on if there are other topic unless there are any final objections? | 16:44 |
| jssfr | I'd probably jump out of the meeting then. I'll stay reachable here as usual though if there's any later remarks. Thanks for all the input! | 16:45 |
| Uggla | ok I guess melwitt point was covered ^ | 16:46 |
| Uggla | anything else to discuss ? | 16:46 |
| jssfr | okay, text you all later, thanks! | 16:47 |
| Uggla | As we are almost on the top of the hour, I'll skip bug scrubbing. | 16:52 |
| Uggla | Thanks all, see you next week. | 16:53 |
| Uggla | #endmeeting | 16:53 |
| opendevmeet | Meeting ended Tue Aug 5 16:53:50 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:53 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.html | 16:53 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.txt | 16:53 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.log.html | 16:53 |
| cardoe | So I know its after the meeting but I just wanted to bring up https://review.opendev.org/c/openstack/nova-specs/+/471815 | 17:09 |
| sean-k-mooney | cardoe: i still think that woudl be good to do, in 2026.1 at this point but its still open because of review banding and process | 17:31 |
| cardoe | So Ironic has implemented a patch that grabs the metadata from nova and rewrites it to add that data and then ultimately writes that to disk. | 17:33 |
| sean-k-mooney | that was added for another reason i belive | 17:34 |
| sean-k-mooney | but yes they have some logic for updatign the config drive | 17:34 |
| sean-k-mooney | that for port_groups in general rather then bonding specificly i think | 17:35 |
| sean-k-mooney | or perhaps its for bonding rather then for vlan trunking | 17:35 |
| sean-k-mooney | i vagly recall the patch but not the details | 17:35 |
| sean-k-mooney | cardoe: https://bugs.launchpad.net/ironic/+bug/2106073 | 17:36 |
| sean-k-mooney | which which was adress by https://review.opendev.org/c/openstack/ironic/+/946677 | 17:37 |
| sean-k-mooney | cardoe: it looks like they have chosen to use the uuid for the link id https://review.opendev.org/c/openstack/ironic/+/946677/29/ironic/conductor/configdrive_utils.py#295 | 17:39 |
| sean-k-mooney | even if that may brake some usescases | 17:39 |
| sean-k-mooney | that effecitvly what i was suggesting doing too | 17:39 |
| cardoe | Well I can update the spec as well. | 17:40 |
| sean-k-mooney | ack they have some examples of what it will looklike in tehre unit tests https://review.opendev.org/c/openstack/ironic/+/946677/29/ironic/tests/unit/conductor/test_configdrive_utils.py#169 | 17:41 |
| cardoe | I'm happy to do whatever you guys would like to see to get it landed. | 17:55 |
| cardoe | I'm merely trying to show users in my company and then at another company (where some former co-workers have gone) that they need to be engaging with upstream instead of downstream patches. | 17:55 |
| cardoe | Which has morphed into me finding that spec and series which is from another company. And the written patches are written by yet another company. | 17:56 |
| cardoe | While my company engages with upstream (hi I'm here) there's other orgs within that don't necessarily. | 17:56 |
| cardoe | Then these other two companies aren't engaging at all. | 17:57 |
| cardoe | You want devs and contributors, well I gotta convince these companies that it's not pointless to engage upstream on features. | 17:57 |
| sean-k-mooney | cardoe: ack Uggla fyi ^ | 18:10 |
| sean-k-mooney | cardoe: its not pointless but someone aslo need to actully do the work and chapiaion the idea. you are promoting it well | 18:10 |
| cardoe | I picked this feature cause I thought it'd be the easiest since it had a spec, an implementation, it had tempest tests for nova, neutron, and ironic | 18:11 |
| sean-k-mooney | right the context that is around it is many core reviewer have been feeling burn out due to the numebr of feature thaty are bign asked to review so it was propsoed that we shoudl approve less specs but try to activlly land the ones we do approve | 18:13 |
| sean-k-mooney | a side effect of that was suggestin that cores shoudl only +2 a spec if they intend to spend time reviewin it | 18:13 |
| sean-k-mooney | that why this didnt progress. its obvious that there is some interest in doing his | 18:14 |
| sean-k-mooney | so i think it could happen next cycle | 18:14 |
| cardoe | okay | 18:25 |
| opendevreview | Callum Dickinson proposed openstack/nova master: Fix image ID in libvirt metadata when unshelving https://review.opendev.org/c/openstack/nova/+/942973 | 21:56 |
| opendevreview | Callum Dickinson proposed openstack/nova master: Add more flavor metadata to libvirt guest XML https://review.opendev.org/c/openstack/nova/+/942974 | 21:56 |
| opendevreview | Callum Dickinson proposed openstack/nova master: Add image meta to libvirt XML metadata https://review.opendev.org/c/openstack/nova/+/942766 | 21:56 |
| Callum027 | sean-k-mooney: Morning, thanks for getting in touch, I've rebased and adopted the suggestions you made to my patches | 22:00 |
| sean-k-mooney | Callum027: thanks, im just wrappiping for today, i proably shoudl have stop about 4 hours ago :) but ill take alook again tomorrow once we get some ci results | 22:03 |
| Callum027 | No worries, have a good evening | 22:03 |
| sean-k-mooney | o/ | 22:04 |
| melwitt | working on code near the server group late affinity check I noticed it looks like there has been a regression in the error handling of the check due to a past bug fix that changed what exception the late check raises https://bugs.launchpad.net/nova/+bug/2119578 | 23:06 |
| melwitt | I just filed a bug to capture it | 23:07 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!