| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 16:14:05 | gibi | this needs to be backported I think | |
| 16:14:10 | gibi | hm | |
| 16:14:23 | gibi | no\ | |
| 16:14:24 | gibi | sorry | |
| 16:14:32 | gibi | I'm not sure | |
| 16:15:28 | gibi | that fix helps with the detach issue on master where we have the new notification based detach | |
| 16:15:46 | sean-k-mooney | it would need to be backported to any release using the events? | |
| 16:15:56 | sean-k-mooney | but not where we poll? | |
| 16:16:12 | sean-k-mooney | so if we backport the events based detach we need to backport both | |
| 16:16:30 | gibi | sean-k-mooney: that is my understanding yes | |
| 16:16:42 | elodilles | I saw lot of failures in victoria as I said, can it be valid backport there? | |
| 16:17:18 | sean-k-mooney | i think its a relitivly safe backport in either case | |
| 16:17:36 | gibi | elodilles: the detach modification is pretty huge patch but it does not change external interfaces | |
| 16:17:51 | sean-k-mooney | gibi: did we backport your events patch to victoria? | |
| 16:17:53 | gibi | so from process perspective it is backportable | |
| 16:17:57 | gibi | sean-k-mooney: no | |
| 16:18:02 | gibi | I dont think so | |
| 16:18:20 | elodilles | anyway, that sound good (except that it's a huge patch :S), I'll add this to my TODO to investigate :) | |
| 16:18:29 | sean-k-mooney | so the failure on vicotria are proably not related to OPERATION_FAILED | |
| 16:18:44 | gibi | sean-k-mooney: yeah | |
| 16:18:45 | sean-k-mooney | elodilles: wehre they OPERATION_FAILED specifcialy or was it just detach failures | |
| 16:19:20 | elodilles | well, the usual error: volume ... failed to detach (in XXXX state ) something | |
| 16:19:46 | sean-k-mooney | ok then that is likely not related to https://review.opendev.org/c/openstack/nova/+/796255 | |
| 16:19:50 | gibi | sean-k-mooney: I dont think nova logs the sepcific error code | |
| 16:19:53 | elodilles | :-/ | |
| 16:19:58 | sean-k-mooney | we can review after the meeting if you have an example | |
| 16:20:23 | elodilles | sure, thanks! | |
| 16:20:25 | gibi | ack | |
| 16:20:28 | sean-k-mooney | gibi: we might see it in the libvirt log in the ci run not sure but just a guess | |
| 16:20:34 | gibi | ok | |
| 16:20:42 | gibi | any other stable related issue? | |
| 16:21:16 | elodilles | nothing else i think :X | |
| 16:22:37 | gibi | #topic Sub/related team Highlights | |
| 16:22:42 | gibi | Libvirt (bauzas) | |
| 16:22:45 | bauzas | just one thing, we discussed about https://review.opendev.org/c/openstack/nova/+/769614 about how to help operators to know about a behaviour modification for a libvirt issue | |
| 16:23:05 | bauzas | we had some argument about some relnote reno section | |
| 16:23:08 | bauzas | but, | |
| 16:23:16 | bauzas | eventually, I +Wd the fix | |
| 16:23:53 | gibi | bauzas: what is the summary? | |
| 16:24:00 | bauzas | do we need to create some better way to tell operators that we no longer verify the cpu topologies ? | |
| 16:24:09 | sean-k-mooney | yes just noticed if you really wanted me to update it i was ok with that just wanted you and stephenfin to agree on a path forward | |
| 16:24:26 | bauzas | gibi: this ^ | |
| 16:24:58 | bauzas | basically, flavors could continue to have the same extraspecs | |
| 16:25:06 | stephenfin | bauzas: I'm still not sure what you're asking for. Are you suggesting we drop the 'upgrade' section? | |
| 16:25:18 | bauzas | stephenfin: no, not about this | |
| 16:25:45 | bauzas | stephenfin: about whether we would need more some kind of documentation for this | |
| 16:25:50 | stephenfin | oh, that | |
| 16:26:03 | sean-k-mooney | oh ok you were conserened if we needed to document it at all | |
| 16:26:10 | sean-k-mooney | not how we did it | |
| 16:26:10 | bauzas | yup | |
| 16:26:29 | sean-k-mooney | ok i tought you just wanted it in the fixes section so i missed that in your previous comments | |
| 16:26:33 | stephenfin | My personal opinion is no. We never documented this behaviour and we never agreed to guarantee it. I wanted to include the release note simply as a courtesy | |
| 16:26:39 | bauzas | basically, the flavors would continue to be the same, it's just the libvirt driver that won't longer verify them | |
| 16:26:54 | stephenfin | similar to how we announce virt API changes, even though we don't support out-of-tree virt drivers | |
| 16:27:16 | stephenfin | I think you've misunderstood things. Nothing changes in what we verify | |
| 16:27:21 | sean-k-mooney | well its not about verificaiotn is that we change unspecified behavior to different unspecifed behavior | |
| 16:27:27 | bauzas | stephenfin: fair enough, I'm having the same opinion but I'm asking the community here if they have concerns | |
| 16:27:34 | stephenfin | yes, what Sean said | |
| 16:28:05 | gibi | if we are changing undefined behavior then reno is just an extra, but not at all mandatory. | |
| 16:28:06 | stephenfin | we had a hidden behavior where we would try to match the number of guest CPU "threads" to the number of host CPU threads | |
| 16:28:25 | stephenfin | but it was hidden. We didn't even know it existed until sean-k-mooney started fixing this bug | |
| 16:28:28 | bauzas | yes, just a performance kind of help | |
| 16:28:37 | stephenfin | exactly. An optimization at most | |
| 16:28:47 | bauzas | okay, any concerns ? | |
| 16:28:52 | bauzas | if not, I'm OK | |
| 16:28:59 | gibi | I'm Ok too | |
| 16:29:20 | gibi | stephenfin, sean-k-mooney: is is settled from your perspective too? | |
| 16:29:25 | stephenfin | no issues from me | |
| 16:29:33 | sean-k-mooney | yep | |
| 16:29:41 | sean-k-mooney | i did not have a stong opiion | |
| 16:29:42 | bauzas | k, that's it for me | |
| 16:29:50 | gibi | ok, thanks | |
| 16:29:57 | gibi | #topic Open discussion | |
| 16:30:03 | gibi | there is one topic | |
| 16:30:07 | gibi | (wenpingsong) vGPU spec reviewing: as we discussed during ptg, cyborg-managed/nova-managed gpu should have a trait indicating who owns this gpu, thanks for bauzas's comments with different thoughts about the trait. We need to have an agreement on that. https://review.opendev.org/c/openstack/nova-specs/+/780452 (can't attending the meeting due to the time slot, but will check the logs later) | |
| 16:30:33 | gibi | as far as I understand we originally suggested the owner traits | |
| 16:30:43 | gibi | but bauzas now suggest using separate RC | |
| 16:30:49 | gibi | for cyborg managed vgpus | |
| 16:30:56 | gibi | this way the trait would not be needed | |
| 16:30:56 | sean-k-mooney | both could work | |
| 16:31:10 | bauzas | my -1 was just for discussing about it | |
| 16:31:25 | gibi | I guess we don't have the use case: Give me a vgpu I don't care if it is cyborg or nova managed | |
| 16:31:30 | bauzas | given I was also working on the mdev spec | |
| 16:31:40 | bauzas | I thought about it | |
| 16:31:43 | sean-k-mooney | owner traits i guess could have upgrade issues | |
| 16:31:49 | bauzas | and I'm not sure we need a "nova" trait | |
| 16:31:51 | sean-k-mooney | e.g. if you upgrade cyborg first | |
| 16:31:59 | sean-k-mooney | without upgrading nova to support owner traits | |
| 16:32:07 | bauzas | I know tho we said we would do it at some PTG | |
| 16:32:19 | bauzas | so I'm sorry to reopen the can | |
| 16:32:44 | sean-k-mooney | well no i think there is a usecase for a nova triat | |
| 16:32:51 | sean-k-mooney | or well RP ownwer in general | |
| 16:32:56 | sean-k-mooney | not nessiarly a trait | |
| 16:33:33 | bauzas | it's the other way of a consumer type :) | |
| 16:33:45 | bauzas | something like a inventory type :) | |
| 16:33:49 | sean-k-mooney | so its a provider type :) | |
| 16:33:58 | bauzas | yeah | |
| 16:34:24 | bauzas | tbh, I don't really like us marking traits for things unnecessary | |
| 16:34:43 | sean-k-mooney | am would it be better to continue this discsssuon on the spec. was tehre a summary you wanted to give in real time | |
| 16:34:51 | bauzas | agreed | |