| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-26 | |||
| 16:25:22 | bauzas | ie. May 10th ? | |
| 16:25:37 | sean-k-mooney | the 10 ya that would be ok i think | |
| 16:26:13 | bauzas | I see no objections | |
| 16:26:23 | gibi | good for me | |
| 16:26:41 | bauzas | #agreed first spec review day will happen on May 10th, bauzas to communicate thru the mailing list | |
| 16:27:09 | bauzas | this leaves 2 weeks for people writing specs, you are warned | |
| 16:27:20 | bauzas | (again, this includes me) | |
| 16:28:17 | bauzas | we'll have another round of spec reviews, as we agreed last PTG, either way | |
| 16:28:51 | bauzas | ok, next | |
| 16:29:00 | bauzas | #topic Review priorities | |
| 16:29:04 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | |
| 16:29:52 | bauzas | the vIOMMU change probably needs paperwork | |
| 16:30:41 | bauzas | tl;dr: https://review.opendev.org/c/openstack/nova/+/830646 requires at least a blueprint, and maybe a spec | |
| 16:30:42 | sean-k-mooney | ya i started to review it i kind of think it shoudl have a mini spec | |
| 16:30:51 | melwitt | +1 | |
| 16:31:09 | bauzas | I can use my hammer | |
| 16:31:21 | bauzas | but I could soften it | |
| 16:31:51 | bauzas | explaining we require a blueprint and some discussion at a nova meeting before we can pursue reviewing it | |
| 16:31:59 | bauzas | ricolin: are you around ? | |
| 16:32:18 | sean-k-mooney | im not againt the proposaly in fact i have wanted to add supprot for a while but we need to agree on the extra_specs/image propeties and define the scope | |
| 16:32:28 | sean-k-mooney | i was recommening keeping it small for now | |
| 16:32:31 | bauzas | yeah, and that's why we need a debate | |
| 16:32:55 | bauzas | not about which paper stamp we should use | |
| 16:33:02 | sean-k-mooney | there is viommu supprot with the limited chagne required for there acclerator to work | |
| 16:33:08 | bauzas | but whether we all agree on the design | |
| 16:33:13 | sean-k-mooney | and then there is full supprot with security and isolation | |
| 16:33:38 | bauzas | correct, that's why we need to discuss this correctly and address the design scope | |
| 16:33:49 | sean-k-mooney | i would suggest we split it like that and only do the former this cycle | |
| 16:34:11 | bauzas | sean-k-mooney: well, we need a owner, at first :) | |
| 16:34:35 | bauzas | even if we agree on the direction, we need gears | |
| 16:34:37 | sean-k-mooney | yep mnaser also expressed interest. im not sure that stephenfin will work on it this cycle | |
| 16:35:05 | bauzas | I'm sure stephenfin said he was okay to leave it for others to continue :) | |
| 16:35:27 | bauzas | hence the gerrit hammer | |
| 16:35:47 | bauzas | this may help people to react and assign some time for this | |
| 16:36:43 | bauzas | I'll also drop the review-prio flag which is meaningless in this case as we can't merge it as it is | |
| 16:37:43 | bauzas | ok, moving on if nobody yells | |
| 16:38:10 | bauzas | #topic Stable Branches | |
| 16:38:14 | bauzas | elodilles: your turn | |
| 16:38:20 | elodilles | #info ussuri and older branches are blocked until 'l-c drop' patches merge - https://review.opendev.org/q/I514f6b337ffefef90a0ce9ab0b4afd083caa277e | |
| 16:38:30 | elodilles | #info other branches should be OK | |
| 16:38:36 | elodilles | #info nova projects' stable/victoria transitioned to Extended Maintenance - no further releases will be produced from victoria, but branch remains open to accept bug fixes | |
| 16:38:44 | elodilles | and that's all I think ^^^ | |
| 16:39:15 | melwitt | we need second core wink wink | |
| 16:39:24 | elodilles | :] | |
| 16:39:41 | gibi | I would be happy to approve... ;) | |
| 16:39:52 | gibi | (has some blocked train backports :D) | |
| 16:40:03 | bauzas | I can do things | |
| 16:40:12 | gibi | bauzas: ask elodilles to add me into the stable-core group | |
| 16:40:12 | bauzas | my brain fsck'd me | |
| 16:40:20 | gibi | then I can help | |
| 16:40:53 | bauzas | gibi: I think we said at the PTG I should propose your name against the stable team | |
| 16:41:01 | gibi | yeah I think so | |
| 16:41:05 | bauzas | so, | |
| 16:41:05 | gibi | so lets do it :D | |
| 16:41:19 | bauzas | #1 I'll do my homework and review such l-c patches | |
| 16:41:53 | bauzas | #2 I'll do my duty and engage discussions about reconciling the nova team and the nova-stable team in some intelligent manner | |
| 16:43:18 | bauzas | last topic in the agenda, | |
| 16:43:21 | bauzas | #topic Open discussion | |
| 16:43:27 | bauzas | (gibi) Allow claiming PCI PF if child VF is unavailable https://review.opendev.org/c/openstack/nova/+/838555 | |
| 16:43:33 | bauzas | gibi: take the mic | |
| 16:43:38 | gibi | thanks | |
| 16:43:45 | gibi | so | |
| 16:43:51 | gibi | it is a bug | |
| 16:43:58 | gibi | we saw DB inconsistencies at customers | |
| 16:44:23 | gibi | the pci_devices table contains available PF and unavailable children VF rows | |
| 16:44:39 | gibi | this basically an impossible situation | |
| 16:44:54 | gibi | the VF should be available if the PF is available | |
| 16:45:04 | gibi | or the VF should be allocated | |
| 16:45:12 | gibi | anyhow | |
| 16:45:26 | gibi | I propsed a fix https://review.opendev.org/c/openstack/nova/+/838555 | |
| 16:45:40 | gibi | it removes some of the strictness of the state check during the PCI claim | |
| 16:45:56 | gibi | basically allows allocating the available PF if the children VFs are unavailable | |
| 16:46:06 | gibi | this would heal the inconsistent DB state | |
| 16:46:13 | gibi | artom had a good point in the review | |
| 16:46:32 | gibi | that we tend to handle DB healing via nova-manage CLI instead | |
| 16:46:45 | bauzas | not true | |
| 16:46:59 | sean-k-mooney | we heal some things on object load form the db | |
| 16:47:02 | bauzas | we had db healing made thru data migrations | |
| 16:47:51 | artom | Right, but those fixes are from "we had thing X a long time ago, and it might still be in the DB, so now when we load it we convert to thing X" | |
| 16:47:59 | sean-k-mooney | we do have the heal allcoation type commands but i think healing this on agent start is the right thing | |
| 16:48:01 | bauzas | we only heal things thru the CLI if this is for example something due to some relationship between two DBs | |
| 16:48:08 | artom | vs examples like placement-audit and Lee's connection_info update | |
| 16:48:09 | sean-k-mooney | as we are also fixing the in memroy representation | |
| 16:48:18 | bauzas | sean-k-mooney: correct, because two DBs were involved | |
| 16:48:52 | artom | My other point was - the DB somehow got into an inconsistent state, wouldn't it be wiser to at least let the operator know, vs siltently fixing it? | |
| 16:48:58 | bauzas | in the case of placement audit, this was about reconciling two datastores kept from two different projects | |
| 16:49:05 | sean-k-mooney | artom: i dont think so | |
| 16:49:17 | bauzas | I agree with sean-k-mooney | |
| 16:49:25 | bauzas | we could log such thing | |
| 16:49:32 | bauzas | but no need to claim it loud | |
| 16:49:32 | sean-k-mooney | artom: i think this happened beacue of how the custoemr recreated the compute node after the hdd died | |
| 16:49:34 | artom | OK :) Not a hill I want to die on, but wanted to at least raise the question | |
| 16:49:35 | gibi | I've added a WARNING log in the patch | |
| 16:49:52 | artom | Seems like I'm outnumbered :) | |
| 16:49:52 | sean-k-mooney | i dont think this is something that most operators would hit | |
| 16:50:12 | bauzas | artom: I won't ask you how many divisions you have | |
| 16:50:19 | gibi | sean-k-mooney: one more thing, you said it should be fixed at agent restart. Now my patch fixes it during PCI claim | |
| 16:50:31 | artom | bauzas, divisions o_O? | |
| 16:50:51 | bauzas | gibi: I like the pci claim approach | |
| 16:51:05 | sean-k-mooney | i have not reviewd the third patch yet | |