| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 16:03:36 | gibi | is there any specific bug that we need to discuss now? | |
| 16:04:10 | sean-k-mooney | gibi: i am pretty sure that https://bugs.launchpad.net/nova/+bug/1933096 | |
| 16:04:16 | sean-k-mooney | is a bug in ther ci env | |
| 16:04:24 | sean-k-mooney | so hopefully we can close that soon | |
| 16:04:45 | gibi | sean-k-mooney: cool. thanks for looking into that | |
| 16:05:53 | gibi | if nothing else then | |
| 16:05:53 | gibi | #topic Gate status | |
| 16:05:58 | gibi | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | |
| 16:06:01 | bauzas | gibi: I'll look at open bugs | |
| 16:06:16 | gibi | bauzas: thank you | |
| 16:06:23 | gibi | I don't see fresh gate bug in that list | |
| 16:06:31 | gibi | last week we merged couple of fixes | |
| 16:06:46 | gibi | how do you feel, does the gate improved? | |
| 16:06:46 | sean-k-mooney | am any suggestions on who i should ping to move https://review.opendev.org/c/openstack/devstack/+/796826 along in devstack | |
| 16:07:06 | bauzas | thanks lyarwood btw. | |
| 16:07:13 | bauzas | for the gate failures fixes | |
| 16:07:44 | gibi | sean-k-mooney: gmann could be one | |
| 16:08:09 | sean-k-mooney | i assume that we are still seeing the intermitant failures due to the agent haning | |
| 16:08:31 | sean-k-mooney | so if we can merge that sooner rather then later it should help with gate stablity | |
| 16:08:32 | gibi | I was off yesterday and did not push any code today so I don't have the view what is failing ont he gate | |
| 16:08:46 | gibi | but I agree that devstack patch is a good step forwa4rd | |
| 16:09:17 | gibi | anything else about the gate? | |
| 16:10:34 | gibi | Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly | |
| 16:10:38 | gibi | placement jobs are green | |
| 16:10:47 | gibi | #topic Release Planning | |
| 16:10:51 | gibi | Milestone 2 is 15 of July which is spec freeze | |
| 16:10:55 | gibi | Spec review day is 6th of July #link http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023083.html | |
| 16:11:01 | gibi | anything else about the coming milestone? | |
| 16:12:47 | gibi | #topic Stable Branches | |
| 16:12:52 | gibi | copying notes from elodilles | |
| 16:12:56 | gibi | stable/ussuri is blocked (fix needs to be merged: https://review.opendev.org/c/openstack/nova/+/794675 ) | |
| 16:13:00 | gibi | other branches should be OK (however, there are quite frequent volume detach failures for example on stable/victoria) | |
| 16:13:05 | gibi | stable/ocata branches of nova are EOL, branches are deleted ( https://review.opendev.org/c/openstack/releases/+/795664 ) | |
| 16:13:08 | gibi | EOM | |
| 16:13:25 | elodilles | sorry, I was lost in the ussuri gate fixing patches, | |
| 16:13:35 | gibi | the detach failure has a fix on master | |
| 16:13:36 | elodilles | i will try to sort it out in the coming days | |
| 16:13:59 | gibi | https://review.opendev.org/c/openstack/nova/+/796255 | |
| 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 | |