Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
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"
14:23:23 admiyo Heh....scope existed from the get go
14:23:36 sean-k-mooney not in anything other then keystone
14:23:52 sean-k-mooney we not only persponed it we removed it form almost every project that impmented it
14:24:18 admiyo Keystone split off from Nova. It was originally implemented there. The bug is Nova's original sin
14:24:34 sean-k-mooney admiyo: to be clear i was not makeign the deciosn to close it form a nova point of view
14:24:56 admiyo And the problem was that there WERE nova apis that required admin scoped to the project
14:24:57 sean-k-mooney as a comuntiy a collect dission was made not to go in that direction
14:25:10 admiyo so you HAD to split it up somehow. So you can fix it, and maybe it is fixed now
14:25:53 sean-k-mooney admiyo: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html or partipated in any of the discussion that have been taking place for the last 5 years on this topic
14:26:18 admiyo I got so burnt out by chasing this that I had to step away from Keystone.
14:26:36 admiyo And I have popped in periodically. The bug was still assigned to me for a while.
14:27:01 admiyo And I think it is ok to say that it is fixed if you cannot have a admin scoped project token
14:27:07 sean-k-mooney admiyo: when we explained to operator that they would not be able to do openstack service list --all-tenant with the proposed implemetion they said hell no
14:27:26 admiyo And there was a solution to that
14:27:45 admiyo That was why we had implied roles.
14:27:55 sean-k-mooney we still have implied roels
14:28:05 sean-k-mooney admin impiles member implies reader
14:28:12 admiyo I know. I wrote that implementation and I can see it has been maintained.
14:28:20 sean-k-mooney that does nto solve the problem when a servier is a proejct scoped resoucece
14:28:39 admiyo Yes it does....
14:29:29 sean-k-mooney well in 5 years noone has been able to expalin how to make it owrk in a way that people can accpet and implemtnet
14:29:38 admiyo You need the appropriate role, but implied roles work down the hierarchy, So if I have the correct role on the parent proejct (or domain) it works for all projects underneath it.

Earlier   Later