| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-23 | |||
| 16:06:05 | bauzas | #topic Review priorities | |
| 16:06:10 | bauzas | #link https://etherpad.opendev.org/p/nova-caracal-status | |
| 16:06:21 | bauzas | time to look at the etherpad if you hadn't yet done it | |
| 16:07:40 | bauzas | aha, split issue :) | |
| 16:07:52 | bauzas | #topic Stable Branches | |
| 16:07:57 | bauzas | elodilles: still around ? | |
| 16:08:02 | elodilles | #info stable gates don't seem blocked | |
| 16:08:09 | elodilles | #info nova stable Zed release is out (nova 26.2.1) | |
| 16:08:14 | bauzas | \o/ | |
| 16:08:21 | elodilles | \o/ | |
| 16:08:23 | elodilles | indeed | |
| 16:08:24 | elodilles | :) | |
| 16:08:27 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:08:34 | elodilles | EOM | |
| 16:09:38 | bauzas | I guess I need to look again at https://review.opendev.org/c/openstack/releases/+/903278 | |
| 16:09:47 | bauzas | (Ussuri EOL patch) | |
| 16:10:05 | elodilles | yepp, a PTL +1 would be nice there :) | |
| 16:10:18 | bauzas | okay, I'll do then | |
| 16:10:34 | elodilles | thanks o/ | |
| 16:11:15 | elodilles | (wanted to ping you with this, off the meeting, but i haven't got there :S) | |
| 16:11:50 | bauzas | cool | |
| 16:12:03 | bauzas | I was also looking at the Unmaintained resolutions | |
| 16:12:22 | bauzas | I wonder when we'll start doing this | |
| 16:12:33 | bauzas | but not a question for here, so moving on | |
| 16:12:40 | elodilles | maybe tomorrow i'll push the transition patches ;) | |
| 16:12:53 | bauzas | aha, gtk | |
| 16:12:54 | sean-k-mooney1 | we were ment to have it completed last cycle | |
| 16:13:03 | sean-k-mooney1 | so sonner rather then later woudl be best | |
| 16:13:44 | bauzas | I know but there were some needed stuff to do before we were able to do this | |
| 16:13:48 | bauzas | like the gerrit team | |
| 16:14:01 | bauzas | so I just wonder where we are | |
| 16:14:13 | bauzas | but anyway | |
| 16:14:17 | bauzas | elodilles: thanks for the good news | |
| 16:14:20 | bauzas | moving on | |
| 16:14:27 | bauzas | other excellent news, | |
| 16:14:32 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:14:39 | fwiesel | #info Security Exemption granted and log hosting enabled | |
| 16:15:04 | fwiesel | So, you should finally be able to download this: https://s3.us-east-2.amazonaws.com/openstack-ci-logs.global.cloud.sap/logs-stack.tar.gz | |
| 16:15:19 | fwiesel | It is just the logs of the stack run I promised the last time | |
| 16:15:20 | sean-k-mooney | yep do you have the logs viewable | |
| 16:15:25 | sean-k-mooney | without downloading them | |
| 16:15:41 | bauzas | <3 | |
| 16:15:51 | sean-k-mooney | i.e. not as a singlel tar but unpackted on the log server | |
| 16:15:56 | fwiesel | Yes, I'll have to put that in a proper form still. | |
| 16:16:17 | sean-k-mooney | cool | |
| 16:16:33 | fwiesel | It's more the point to show that we did run someting in the past, and it worked, and now you can see it. | |
| 16:16:37 | fwiesel | #info CI added to Wiki | |
| 16:16:42 | fwiesel | #link https://wiki.openstack.org/wiki/ThirdPartySystems/vmwareapi_CI_run_by_SAP | |
| 16:16:49 | bauzas | excellent | |
| 16:16:50 | fwiesel | Nothing spectacular. | |
| 16:16:57 | fwiesel | #info CI gets triggered by gerrit patch-set (or 'recheck' comment) and serially creates devstack with the specified version, cleans up afterwards (rinse and repeat) | |
| 16:17:40 | fwiesel | So, we get until the devstack automatically. | |
| 16:17:45 | fwiesel | #info Manual tempest. Ran: 379 tests in 3912 sec. Passed: 241, Failed: 107. | |
| 16:18:07 | fwiesel | I just need to get that into the pipeline and ship the logs. | |
| 16:18:10 | bauzas | fwiesel: could we be able to see all the job runs in some link ? for example, to see if *all | |
| 16:18:20 | bauzas | changes are getting a FAILURE or not | |
| 16:19:01 | bauzas | formerly, we had a 3rd-party CI link that was telling us that, but this is no longer working :( | |
| 16:19:15 | bauzas | ciwatch.mmedvede.net/project?project=nova | |
| 16:19:40 | fwiesel | bauzas: That's probably doable, but needs to be implemented somehow... The ci itself is not open to the internet and opening that up will be a bit of an effort | |
| 16:20:20 | bauzas | fwiesel: I understand this would be a new /feature/ | |
| 16:20:22 | fwiesel | I could definitely put that on the same AWS bucket | |
| 16:20:35 | bauzas | fwiesel: my concern is to not ping you for any failure I'm seeing | |
| 16:20:56 | bauzas | rather if I'm seeing like 90% of the changes getting a failure | |
| 16:21:30 | fwiesel | bauzas: Sure, that can be done. What priority would that have? Compared to commenting on the change request? | |
| 16:22:18 | bauzas | fwiesel: I don't know tbh, this is more about knowing whether we need to ping you or not :p | |
| 16:22:26 | bauzas | but we can start | |
| 16:23:03 | fwiesel | Okay, I'll add it then afterwards. | |
| 16:23:11 | sean-k-mooney | commenting on the change request is the imporant thing | |
| 16:23:30 | sean-k-mooney | having a way to see if the job are generally passing or failing is a nice to have after | |
| 16:23:38 | bauzas | correct | |
| 16:23:57 | fwiesel | I was assuming it, but maybe in the beginning you might trust the ci less and want to see that it produces green builds first | |
| 16:24:17 | fwiesel | Before spamming the changes with messages which are actually faults of the CI | |
| 16:24:32 | bauzas | yeah, most of people would recheck | |
| 16:24:36 | sean-k-mooney | well the ci wont actuly block the patch merging | |
| 16:24:46 | bauzas | but yeah, what sean-k-mooney said | |
| 16:24:58 | sean-k-mooney | so at the start we can just leave it to the reviews to check the ci output when it fails | |
| 16:25:15 | fwiesel | Great, then I'll first do the browsable logs and the comments. | |
| 16:25:25 | sean-k-mooney | +1 | |
| 16:25:27 | bauzas | somehow we *eventually* need this for knowing we're done | |
| 16:25:40 | bauzas | but yeah, agreed on the other prios first | |
| 16:25:44 | bauzas | and the reviewable link | |
| 16:25:55 | bauzas | I mean the browsable logs first | |
| 16:26:28 | bauzas | that's still excellent news to know that everything is in place :) | |
| 16:26:35 | bauzas | kudos to you, fwiesel and grandchild | |
| 16:26:36 | fwiesel | "Browseable" means it is okay if it is done in the browser with javascript? Or does it need to be unpacked on the server? | |
| 16:26:54 | grandchild | fwiesel did all the work -- can't take credit :) | |
| 16:27:10 | bauzas | fwiesel: both ? :D | |
| 16:27:17 | sean-k-mooney | normally we convert the logs to html | |
| 16:27:30 | sean-k-mooney | so that we can get clickable links to lines | |
| 16:27:38 | sean-k-mooney | to show this is why x failed | |
| 16:27:54 | bauzas | some others just directly look at the files :p | |
| 16:28:09 | sean-k-mooney | so i would like it to at least be linkable and viewabel | |
| 16:28:40 | sean-k-mooney | the simplest way to do that is normally just enabel directory listing on the server | |
| 16:28:40 | fwiesel | Okay, I'll see what I can do. | |
| 16:28:42 | bauzas | well, on my side, I'd prefer raw files that I could open | |
| 16:28:50 | bauzas | so yeah, unpack first | |
| 16:28:57 | fwiesel | Well, with s3 buckets, there is no directory listing :) | |
| 16:28:58 | dansmith | definitely unpack | |
| 16:29:17 | dansmith | fwiesel: then just generate an HTML file with links to the files and upload that too | |
| 16:29:40 | fwiesel | That I can easily do. | |