| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-19 | |||
| 16:17:30 | sean-k-mooney | there are a few poepl that tend to only review +1 | |
| 16:17:41 | sean-k-mooney | and i wonder if its the same subset that are blind rechecking | |
| 16:17:51 | sean-k-mooney | i did ask one person to stopp rechecking | |
| 16:18:01 | sean-k-mooney | becuase there was an actual issue | |
| 16:19:51 | sean-k-mooney | anyway lets move on we can chat about this after the meeting | |
| 16:20:20 | bauzas | okay | |
| 16:20:43 | bauzas | #topic Release Planning | |
| 16:20:47 | bauzas | #link https://releases.openstack.org/caracal/schedule.html#nova | |
| 16:20:50 | bauzas | #info RC1 delivered this morning | |
| 16:20:52 | bauzas | \œ/ | |
| 16:21:06 | bauzas | #info master branch is now on Dalmatian | |
| 16:21:16 | elodilles | \o/ | |
| 16:21:47 | bauzas | as a reminder, we won't accept backports for the caracal branch until GA unless they are regression fixes | |
| 16:22:20 | bauzas | ditto with other stable backports given you need to have it in Caracal too | |
| 16:22:39 | bauzas | (unless of course the backports are from a caracal merged change) | |
| 16:22:47 | elodilles | +1 | |
| 16:23:08 | bauzas | #link https://etherpad.opendev.org/p/nova-caracal-rc-potential | |
| 16:23:26 | bauzas | I'll continue to provide this etherpad for the possible new Caracal RC tags | |
| 16:23:45 | bauzas | I just hope we won't find a regression | |
| 16:24:09 | bauzas | any question about RC phases or Dalmatian ? | |
| 16:25:22 | bauzas | looks not, moving on | |
| 16:25:48 | bauzas | #topic Review priorities | |
| 16:26:01 | bauzas | #action bauzas to provide a new etherpad for Dalmatian | |
| 16:26:13 | bauzas | for the moment, we don't have priorities | |
| 16:26:21 | bauzas | I'll start to look at some spec changes next week | |
| 16:26:40 | bauzas | #topic Stable Branches | |
| 16:26:43 | bauzas | elodilles: go for it | |
| 16:26:47 | elodilles | o/ | |
| 16:26:50 | elodilles | #info stable/2024.1 branch is open for bugfix backports | |
| 16:27:01 | elodilles | of course as bauzas wrote: only rc critical | |
| 16:27:04 | elodilles | for this time | |
| 16:27:11 | elodilles | #info stable gates seem to be OK | |
| 16:27:45 | bauzas | cool | |
| 16:27:56 | elodilles | (as we discussed, there are jobs that fail intermittently :/) | |
| 16:28:05 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:28:33 | elodilles | that's it from me about stable branches | |
| 16:29:38 | bauzas | cool thanks | |
| 16:29:45 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:29:47 | bauzas | fwiesel: ? | |
| 16:29:57 | fwiesel | #info CI comments on openstack/nova CR confirmed to be working. | |
| 16:30:06 | fwiesel | Best maybe seen here: | |
| 16:30:08 | fwiesel | #link https://review.opendev.org/dashboard/36571 | |
| 16:30:32 | fwiesel | #info Fixed FIPs instability. Tests quite reproducible. Only one error left with all proposed patches applied. | |
| 16:30:54 | fwiesel | The issue and fix were in retrospect easy... we have now a working pipeline. | |
| 16:31:01 | bauzas | \o/ | |
| 16:31:28 | fwiesel | Just with the new branches came in some instability, as it expects all service to actually have the branch. | |
| 16:32:00 | fwiesel | I.e. it fails now to check out stable/2024.1 for requirements, but we have it in nova. Not sure, if I should do something about that one. | |
| 16:32:14 | fwiesel | Missed that one: | |
| 16:32:15 | fwiesel | #link http://openstack-ci-logs.global.cloud.sap/sapcc-nova--nmllh/tempest.html | |
| 16:32:29 | fwiesel | The tempest test with the last open problem. | |
| 16:32:30 | elodilles | now ~everything should have branched (well, requirements, devstack and grenade will be created around end of week) | |
| 16:32:38 | bauzas | are you sure you use the requirements from the stable releases ? | |
| 16:32:55 | bauzas | fwiesel: awesome about where you are | |
| 16:33:32 | fwiesel | Missing now are hopefully only cleaning up the rough edges... A nicer UI with linkable lines we still are missing. | |
| 16:34:45 | bauzas | okay, anything else ? | |
| 16:34:52 | fwiesel | No, not from my side. | |
| 16:35:00 | fwiesel | Questions? | |
| 16:35:41 | fwiesel | One remark: A test run with fixes in place takes roughly 20minutes in total. | |
| 16:35:42 | bauzas | nope | |
| 16:35:51 | bauzas | wow | |
| 16:36:27 | fwiesel | bauzas: Back to you then | |
| 16:36:43 | bauzas | cool, that will be short | |
| 16:36:51 | bauzas | #topic Open discussion | |
| 16:36:55 | bauzas | anyuthing anyone ? | |
| 16:37:04 | dansmith | a tempest run takes 20 minutes? that would be shockingly fasty | |
| 16:37:52 | fwiesel | Well, it is a hefty machine, and I run it as parallel as I can. | |
| 16:38:19 | bauzas | ok guys, I think I can close the meeting | |
| 16:38:21 | bauzas | thanks all | |
| 16:38:23 | bauzas | #endmeeting | |
| 16:38:23 | opendevmeet | Meeting ended Tue Mar 19 16:38:23 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:38:23 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-19-16.00.html | |
| 16:38:23 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-19-16.00.txt | |
| 16:38:23 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-19-16.00.log.html | |
| 16:38:28 | fwiesel | Thank you too | |
| 16:38:37 | sean-k-mooney | well i guess it depend on how many tests you run. devstack can stack in about 8 mins if its not io bound | |
| 16:39:03 | elodilles | thanks o/ | |
| 16:39:40 | fwiesel | The tempest run takes 10 minutes, by the way :) | |
| 16:40:19 | sean-k-mooney | yep but your also unly runnign 525 ish tests | |
| 16:40:31 | sean-k-mooney | at least based on | |
| 16:40:33 | fwiesel | Sure, are there tests I am missing? | |
| 16:40:33 | sean-k-mooney | http://openstack-ci-logs.global.cloud.sap/openstack-nova-909474-f54wv/tempest.html | |
| 16:40:57 | sean-k-mooney | fwiesel: well you only runing the compute api tests | |
| 16:41:16 | sean-k-mooney | your not runng the senario tests ro any fo teh test fo other services like cinder/nuetorn extra | |
| 16:41:25 | sean-k-mooney | we dont need you to run all of those | |
| 16:41:40 | sean-k-mooney | but i was just providing context for others | |
| 16:41:47 | sean-k-mooney | i.e. its not tempest-full | |
| 16:42:45 | fwiesel | No, indeed it isn't. | |
| 16:43:26 | fwiesel | I am not even running all compute.api-tests, only those that are implemented for the vmware api driver. | |
| 16:43:51 | sean-k-mooney | ack that kind of makes sense | |
| 16:44:11 | sean-k-mooney | for the hardware based cis they took a simialr approch | |
| 16:44:38 | sean-k-mooney | i.e. the old intel ci just ran the cpu pinning/sriov/numa related subset | |
| 16:46:22 | fwiesel | Possibly it would make sense to check what code-coverage the tempest test generates on the driver implementation, and adjust the tests accordingly. | |
| 17:55:03 | sean-k-mooney | dansmith: correct me if im wrong but we do not have the ablity to ask placement for a host that does not have a resouce type right like a forbiden trait, we would have to do that in a scheduler filter | |
| 17:56:42 | sean-k-mooney | related to our converation about non numa instances | |
| 17:56:49 | dansmith | sean-k-mooney: I really don't know currently, but I'm pretty sure that was one of the early limitations.. we could ask for inclusion but not exclusion | |
| 17:57:27 | sean-k-mooney | ack i think its still that way. i belive we coudl have a new filter that does the following check | |
| 17:58:26 | sean-k-mooney | for a given instance look at the guest falvor/image to see if it is requesting numa aware memory i.e. hw:mem_page_size | |
| 17:58:54 | sean-k-mooney | if it is not check the allcoation candates for the host to see if it has either the file backed memory trait or an inventory of PCPU | |
| 17:59:02 | sean-k-mooney | if it has either reject the host | |
| 18:00:05 | sean-k-mooney | that would allow operators to opt in/out by not using the filter | |