| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | |
| 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: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: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | |
| 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: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 | 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:15:03 | admiyo | to Nova. https://adam.younglogic.com/2017/05/fixing-bug-96869/ | |
| 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 | |
| 14:20:58 | admiyo | And the reason why it has stuck around is that Nova scoped APIs to projects that needed the Aadmin role. It can't be fixed in openstack without being fixed in Nova | |
| 14:21:06 | admiyo | What I wrote up was the "hard" way | |
| 14:21:16 | admiyo | the even harder way was to fix all of the APIs in Nova | |
| 14:21:22 | sean-k-mooney | amorin: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | |
| 14:21:34 | sean-k-mooney | amorin: you cant have a proejct scoped admin role in any project | |
| 14:21:37 | sean-k-mooney | its not just nova | |
| 14:21:57 | admiyo | We just killed the Admin role? | |
| 14:22:05 | sean-k-mooney | no | |
| 14:22:53 | sean-k-mooney | the admin role is defiend as a role that allows the bearer to performe admin operations on any service agaisnt any project | |
| 14:23:10 | sean-k-mooney | which is what it has alwasys ment | |
| 14:23:15 | admiyo | "we decided to postpone the scope implementation" | |