Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
02:03:38 opendevreview Takashi Kajinami proposed openstack/placement master: Switch python version for placement-nova-tox-functional https://review.opendev.org/c/openstack/placement/+/932472
02:17:45 opendevreview Takashi Kajinami proposed openstack/os-vif master: Drop kuryr-kubernetes job https://review.opendev.org/c/openstack/os-vif/+/932474
04:17:27 opendevreview Takashi Kajinami proposed openstack/placement master: Switch python version used for periodic jobs https://review.opendev.org/c/openstack/placement/+/932472
04:23:56 opendevreview melanie witt proposed openstack/nova master: WIP trait, filter, request spec https://review.opendev.org/c/openstack/nova/+/932153
06:58:14 opendevreview melanie witt proposed openstack/nova master: api: Add microversion 2.97 to add image_type to block_device_mapping_v2 https://review.opendev.org/c/openstack/nova/+/930968
09:07:49 auniyal https://review.opendev.org/c/openstack/nova/+/926521 - melwittis +2 on this already
09:07:49 auniyal https://review.opendev.org/c/openstack/nova/+/929858
09:07:49 auniyal sean-k-mooney can you please have another look on these
10:45:05 tkajinam so for some reason placement-nova-tox-functional-py39 uses python 3.8 actually. I wonder if we can migrate that job to noble which uses 3.12 by default. https://review.opendev.org/c/openstack/placement/+/932472
10:45:26 sean-k-mooney ah is that why that failed
10:45:30 tkajinam though we may want to fix that inconsistency in stable branches (especially 2024.2 )
10:45:31 tkajinam yeah
10:46:18 sean-k-mooney +2
10:46:23 tkajinam that's truly wired
10:46:27 sean-k-mooney i have approved the nova and os-vif bumps
10:46:37 tkajinam thanks !
10:47:55 sean-k-mooney i wonder if its related to the min tox version we are using
10:48:12 sean-k-mooney minversion = 3.18.0 vs minversion = 4.6.0 in nova
10:49:16 tkajinam minversion only determines min and would not decide the version actually used.
10:49:20 tkajinam tox-4.21.2-py3-none-any.whl is what is pulled in the job
10:49:23 sean-k-mooney https://github.com/openstack/placement/commit/1c8afcd3f10a2ace8fdbada4f758b27bb2774cec
10:49:56 sean-k-mooney so when we bumped to 4.0 we were able to drop ignore_basepython_conflict = True
10:50:01 sean-k-mooney on ok
10:50:12 sean-k-mooney ya that makes sense you cant use tox to install tox
11:28:57 gibi sean-k-mooney: could you please check my test results in https://bugs.launchpad.net/nova/+bug/2077070/comments/7 regarding the pci_devices cleanup at compute_node delete.
11:29:31 gibi sean-k-mooney: other than the discover_hosts complication I will dig later, I don't see any real bugs.
11:29:52 sean-k-mooney are you testign a fix or trying to repoduce
11:30:40 gibi I only trying to reproduce
11:30:50 sean-k-mooney so "nova-manage db archive_deleted_rows" shoudl not be requried to be able to crate a new compute node
11:30:58 gibi it is not required
11:31:18 sean-k-mooney ok so the compute node is marked as deleted?
11:31:28 sean-k-mooney when the compute service is deleted?
11:31:51 sean-k-mooney ill read your comment poeprly
11:32:17 gibi yes, the compute_node is marked deleted
11:32:38 gibi the pci_devices rows are not marked deleted but they are pointing to a compute that is marked deleted so they does not interfere
11:33:22 gibi and archive deletes both the compute_node and the pci_devices rows
11:34:04 gibi this might clarify it further https://bugs.launchpad.net/nova/+bug/2077070/comments/9
11:34:07 sean-k-mooney reading your comemnt ohter then it not workint without --by-service
11:34:15 sean-k-mooney it seams reasonable
11:34:48 sean-k-mooney i susppect the --by-service thing is what was really the issue then
11:34:59 sean-k-mooney tripleo or the end user were problly not using that
11:35:30 gibi yeah, I will dig into that side of the issue as we might fix the discover_hosts to work with undeleted computes
11:37:34 sean-k-mooney im sure you had but just double chekcing you had pci devices in the pci_device table when checking this right
11:39:19 opendevreview Merged openstack/nova master: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/926521
11:39:20 sean-k-mooney im wonderign if an instance was using one and you evacuated it will the archive still work
11:39:25 sean-k-mooney or the undelete
11:40:51 gibi yes, I had pci device even allocated :)
11:41:31 gibi I can try the evac case, as I local deleted the instance after the simulated compute failure
11:42:22 sean-k-mooney so in the evacuate case wehre your keepign the identity
11:42:39 sean-k-mooney there is extra logic in the compute agent to properly clean up after the evacuated instnaces
11:42:50 sean-k-mooney so im wondering if that could be relevent here
11:43:25 sean-k-mooney it proably does not hurt to test wtih the removal of the compute uuid file too but im more concerned about the ohter case
11:47:24 gibi OK. I will check the two case with evac today...
11:47:34 gibi thanks for the review on the bug
12:57:05 opendevreview Merged openstack/nova master: Remove Python 3.8 support https://review.opendev.org/c/openstack/nova/+/931047
12:59:35 opendevreview Merged openstack/os-vif master: Remove Python 3.8 support https://review.opendev.org/c/openstack/os-vif/+/931480
13:03:25 tkajinam My I ask for 2nd vote for https://review.opendev.org/c/openstack/placement/+/932472 to unblock py38 removal ?
13:03:41 tkajinam (I guess the existing job fails because now nova requires python >= 3.9
13:04:23 gibi tkajinam: +A, thanks
13:05:03 tkajinam gibi, thank you, too !
13:08:10 gibi tkajinam: also thanks for the reviews on my igb series. I will quickly respin it to implement you suggestion about value/values
13:13:37 tkajinam gibi, ah, yes. thanks.
13:15:54 tkajinam alternatively we can implement raise_on_too_new_value as a wrapper of raise_on_too_new_values (then we don't have to maintain the same logic twice) but I feel like it's still redundant
13:16:32 tkajinam hopefully we can add typing to avoid wrong usage of raise_on_too_new_values
13:17:23 tkajinam (to prevent someone from using value"s" for a single string
13:23:17 rpittau hi all! I was looking at the PTG schedule for next week and wondering when we could have a joint session between ironic and nova, looks like thursday 24 may be a good day, at 13 UTC, wdyt?
13:28:15 gibi tkajinam: adding typing is not easy as I cannot just require that the passed in value is an iterable as if a single string is passed in it is still an iterable
13:29:41 tkajinam gibi, ah, yes. that's a good point
13:31:10 gibi but unit test should catch these
13:31:14 gibi so I'm not that worried
13:31:23 tkajinam anyway this is rather a global issue and so far the "values" naming should help identifying the expected type
13:31:24 tkajinam yeah
13:34:30 tkajinam rpittau, I think that works. some of the people may be busy on Monday and Wednesday for tc discussion or cross project discussions but may be flexible on Tuesday or Thursday
13:34:47 tkajinam rpittau, though I'd defer the decision to bauzas
13:35:15 rpittau thanks, I chose thursday as for ironic is the less busy day
13:43:34 opendevreview Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590
13:43:35 opendevreview Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584
13:43:35 opendevreview Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456
13:43:36 opendevreview Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
13:43:52 opendevreview Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590
13:43:53 opendevreview Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584
13:43:53 opendevreview Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456
13:43:54 opendevreview Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
13:44:04 gibi tkajinam: fixed your comment :) ^^
13:46:54 tkajinam gibi, thanks !
13:56:35 bauzas rpittau: fair enough, we can do this at Thursday 13OOUTC
13:57:07 bauzas rpittau: adding it now in https://etherpad.opendev.org/p/nova-2025.1-ptg
13:57:12 rpittau bauzas: thanks, I'll update our schedule!
13:57:16 bauzas in our room or yours ?
13:57:35 rpittau we don;t have one booked at that time, maybe better yours
13:58:08 bauzas okay so please join the austin room :)
13:58:33 rpittau we will, thanks :)
13:58:45 bauzas rpittau: added it in https://etherpad.opendev.org/p/nova-2025.1-ptg#L69
14:00:06 rpittau perfect, I've added it at https://etherpad.opendev.org/p/ironic-ptg-october-2024#L10
14:15:03 admiyo to Nova. https://adam.younglogic.com/2017/05/fixing-bug-96869/
14:15:03 admiyo sean-k-mooney, I see that you closed bug 698696 as won;t fix: https://bugs.launchpad.net/keystone/+bug/968696 I think that is a mistake. All role assignments are scoped. I had a proposal a few years back that addresses your concerns. Basically, for "global" actions that nova has scoped to a proejcct (due to history) you confirm that the project on the token is an "administrative" project. It requires minimal changes
14:19:30 sean-k-mooney admiyo: there is no such thing as a project scoped admin
14:20:05 sean-k-mooney admiyo: there is a governance document to descibe how roels shoudl work consitnatnly across all of openstack
14:20:26 admiyo sean-k-mooney, as of when? When Openstack started, that was all there was. It was a bug in the initial design, before Keystone was a project/
14:20:30 sean-k-mooney the admin role is not scoped to a project based on the desgin agreed in yoga

Earlier   Later