| opendevreview | OpenStack Proposal Bot proposed openstack/project-config master: Normalize projects.yaml https://review.opendev.org/c/openstack/project-config/+/887909 | 02:51 |
|---|---|---|
| opendevreview | Merged openstack/project-config master: Normalize projects.yaml https://review.opendev.org/c/openstack/project-config/+/887909 | 08:50 |
| opendevreview | Rafal Lal proposed openstack/project-config master: Add Intel Ethernet Operator app to StarlingX https://review.opendev.org/c/openstack/project-config/+/887941 | 10:23 |
| opendevreview | Elod Illes proposed openstack/openstack-zuul-jobs master: WIP: Cleanup orphan jobs after stable/train EOL of nova https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/887950 | 12:26 |
| elodilles | fyi, some EOL patches landed recently so I'm planning to run the EOL cleanup script as usual | 14:50 |
| elodilles | if there won't be a gerrit upgrade or something similar o:) | 14:51 |
| frickler | I'm not aware of anything | 14:53 |
| elodilles | ACK, thanks frickler o/ | 14:54 |
| fungi | yeah, no plans for today. thanks for the heads up! | 15:06 |
| elodilles | this is the list of the deleted branches for this time: https://paste.opendev.org/show/bdoMyfVkEYJwJ2X7Xtbb/ | 15:33 |
| fungi | buhbye rocky! | 15:34 |
| elodilles | there are still some repos that needs a PTL approval for the rocky-eol patch to merge, but we are pretty close now to finish with stable/rocky o:) | 15:46 |
| elodilles | then i'll propose the stein-eol patches \o/ | 15:47 |
| elodilles | hopefully we can close the majority of the remaining open stable/stein branches before the community kills the EM process :D | 15:48 |
| elodilles | i mean, most of the core projects are long EOL'd on stable/stein, but there are still a good amount... even some that have periodic-stable job failures... | 15:49 |
| elodilles | when those get EOL'd we will half again the daily count of the stable-maint mails o:) | 15:50 |
| fungi | very nice! it's already down to around 35 | 15:52 |
| kozhukalov | Hi folks. Can someone tell me please what does the prefix `nested-virt-` mean in many nodepool labels? | 21:11 |
| kozhukalov | Does this mean that these nodes are VMs? | 21:13 |
| fungi | kozhukalov: it means that the donor clouds providing those nodes expect nested virtualization acceleration in the linux kernel to work reliably, and their operators will try to collaborate with you to troubleshoot things if nested virt accel breaks things | 21:18 |
| kozhukalov | Thanks a lot for the info. | 21:19 |
| fungi | kozhukalov: basically use those labels if you need to do performant virtualization on a test node, but be aware that availability of those nodes is limited and we don't have nearly as many redundant providers for them as we do our normal labels | 21:21 |
| fungi | also, all out nodes are virtual machines | 21:22 |
| fungi | s/out/our/ | 21:22 |
| fungi | which is why having working nested virt accel may be relevant for some job workloads | 21:22 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!