| *** bauzas_ is now known as bauzas | 02:45 | |
| *** bauzas_ is now known as bauzas | 07:30 | |
| jamespage | hi hi - please could we get https://review.opendev.org/c/openstack/project-config/+/917827 landed - I'd like to get the retirement process completed as its been kicking around a while | 07:44 |
|---|---|---|
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Improve systemd services start https://review.opendev.org/c/openstack/ci-log-processing/+/926046 | 10:12 |
| jamespage | frickler: ok so give me a clue because I;m really not getting how to get myself out of groundhog day | 12:18 |
| jamespage | all of the repos are in the state where they have README, gitreview and zuul config (which is no-op) - I need to remove the zuul configuration to be compliant with the goverance check | 12:19 |
| jamespage | is official-openstack-repo-jobs sufficient todo that? | 12:20 |
| opendevreview | James Page proposed openstack/project-config master: Prep sunbeam single charm repos for retirement https://review.opendev.org/c/openstack/project-config/+/917827 | 12:22 |
| jamespage | example - https://review.opendev.org/c/openstack/charm-ops-sunbeam/+/926056 | 12:25 |
| *** bauzas_ is now known as bauzas | 13:27 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Improve systemd services start https://review.opendev.org/c/openstack/ci-log-processing/+/926046 | 13:34 |
| opendevreview | Merged openstack/ci-log-processing master: Improve systemd services start https://review.opendev.org/c/openstack/ci-log-processing/+/926046 | 14:22 |
| clarkb | sean-k-mooney: frickler: we have never supported specific point releases of centos because they are not supported once the new point releases come out. It would also lead to a massive proliferation of images and we're already struggling to claen up old images that are not well used but all over CI configs. Is there some reason we can't just use rocky 9 and then 10 and so on | 15:34 |
| clarkb | as we did back when centos existed? | 15:34 |
| fungi | i'll note this is the same reason we only do ubuntu lts, it requires new images every 2 years rather than every 6 months | 15:39 |
| clarkb | jamespage: frickler: I left a comment on 917827. Hopefully that clarifies things for frickler ? | 15:41 |
| clarkb | but I think that change lgtm now | 15:41 |
| jamespage | clarkb: I'm not sure | 15:42 |
| jamespage | clarkb: I put up https://review.opendev.org/c/openstack/charm-ops-sunbeam/+/926056 as a test | 15:43 |
| clarkb | oh looks like that isn't merging because of the lack of noop jobs | 15:43 |
| clarkb | I see what frickler was asking about now. So maybe 917827 should add noop jobs to the regex match and the charm-openstack-hypervisor project | 15:44 |
| clarkb | then after things are updated and replicated we can unwind all of that | 15:44 |
| jamespage | yep that one | 15:46 |
| jamespage | clarkb: is that in addition to the openstack-official-jobs ? | 15:47 |
| clarkb | jamespage: yes the noop-job template will allow you to approve changes like 926056 and have them land without any true ci running (the noop stuff is a built in escape hatch in zuul). Then the official jobs template will run replication jobs to github. The pair of the two templates should allow you to both merge and replicate things to finalize the cleanup | 15:48 |
| jamespage | let me refresh that review | 15:48 |
| fungi | right, https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/project-templates.yaml#L3520-L3534 only runs things in the post and pre-release/release pipelines, noop-jobs adds empty jobs to check and gate | 15:49 |
| clarkb | I think adding the noop jobs to the regex match may add extar noop jobs to other repos that match the regex but it shouldn't be a real issue other than adding a new job that does nothing to those projects temporarily | 15:50 |
| opendevreview | James Page proposed openstack/project-config master: Prep sunbeam single charm repos for retirement https://review.opendev.org/c/openstack/project-config/+/917827 | 15:51 |
| clarkb | ya that looks right. We land that, you update the repos to say they are all retired and cleaned up, let that replicate to github, then we can clean up further in project-config | 15:52 |
| jamespage | \o/ | 15:53 |
| sean-k-mooney | clarkb: not specificlly i was bassically thinkg why not pin every slup or non slurp and use the ame for a year but following rocky 9 latest and rocky 10 latest would also be fine | 16:20 |
| sean-k-mooney | it already will be more stable then stream so pining to the point release proably is not required | 16:21 |
| sean-k-mooney | i was just suggestin gtratign the even number point releases as the "lts" version | 16:22 |
| clarkb | ah my understanding is that isn't how enterprise linux releases work | 16:22 |
| clarkb | but I may be mistaken. I was under the impression that you are expected to update as security fixes and the like do not go on older point releases | 16:22 |
| sean-k-mooney | well rhel chooses an point releases to prove Extened update support EUS too meaning releses where the rhel team do backport | 16:23 |
| sean-k-mooney | and for 8/9 it has effectivly been ever even relese i think but i have not checked in a while | 16:23 |
| clarkb | https://endoflife.date/rocky-linux this says rocky linux does not support point releases (not sure ifthat site is authoritative) | 16:24 |
| clarkb | so ya we should not try to fix on any point releases even if we were able to make it work with all the extra images that implies | 16:24 |
| sean-k-mooney | ack well we shoudl actully follow the distos info not rhels anyway | 16:24 |
| clarkb | or rather they don't support older point releases. The current one is the supported one | 16:25 |
| sean-k-mooney | clarkb: well it would not be a lot of extra images just 1 i think the current slupr and previous | 16:25 |
| sean-k-mooney | but ya thats fine by me | 16:25 |
| sean-k-mooney | ideally we will move to rocky 10 next release and drop rocky 9 and centos 9 stream ectra in 2025.2 anyway | 16:26 |
| clarkb | and you can use those images today | 16:26 |
| frickler | jamespage: if you're still around I think you misplaced the added comment position in https://review.opendev.org/c/openstack/project-config/+/917827 , I can also amend this myself otherwise | 16:26 |
| sean-k-mooney | clarkb: https://access.redhat.com/support/policy/updates/errata/#RHEL9_Planning_Guide is the public refernce for rhel lifecycle for what its worth | 16:27 |
| opendevreview | James Page proposed openstack/project-config master: Prep sunbeam single charm repos for retirement https://review.opendev.org/c/openstack/project-config/+/917827 | 16:28 |
| jamespage | frickler: still here - amended ^^ :) | 16:28 |
| sean-k-mooney | clarkb: so to pivot the converstaion slightly i assuem we are ok to add rocky 10 when that becomes aviable for 2025.1 | 16:28 |
| clarkb | sean-k-mooney: yes | 16:29 |
| sean-k-mooney | we will proably want to start with centos stream 10 since that already out but i would prefer to use rocky if it was aviablie in time | 16:30 |
| sean-k-mooney | no idea what there actual plan is there | 16:30 |
| sean-k-mooney | rocky 10 will likely be too late for 2025.1 | 16:31 |
| clarkb | its largely up to whoever decides they are interested in pushing that along. NeilHanlon (is in the opendev channel but not here) has been helpful in getting rocky things working for us over time. But others may be interested too | 16:31 |
| sean-k-mooney | since rhel 10 wont be out when we start 2025.1 | 16:31 |
| fungi | mnasiadka has also expressed interest in rocky-related topics in the past, i think | 16:32 |
| frickler | kolla does use rocky instead of centos for some time now, yes | 16:33 |
| sean-k-mooney | ya so if they plan to be binary compatiable with rhel 10 that wont lauch in time for 2025.1 but shoudl be there for 2026.1 | 16:34 |
| sean-k-mooney | centos 10 is already aviable https://composes.stream.centos.org/stream-10/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ | 16:34 |
| fungi | i think the main topic for more immediate discussion is whether/when/how we add rocky package mirroring | 16:34 |
| sean-k-mooney | ya and if we only have the latest version that makes that simpler | 16:35 |
| fungi | we probably have room for it in afs now, dropping xenial i guess will give us more breathing room though | 16:35 |
| clarkb | the way support timelines work we don't really ever have the latest version | 16:35 |
| clarkb | fedora was the lone exception to that | 16:35 |
| clarkb | we should anticipate that we'll end up with ~3 rocky releases over time rolling around | 16:35 |
| sean-k-mooney | why 3 | 16:35 |
| clarkb | (which is fine, I just don't want people to think you can stick to latest only it really doesnt' work out that way with how quicky people update jobs) | 16:35 |
| sean-k-mooney | we already dont supprot rocky 8 | 16:36 |
| clarkb | sean-k-mooney: because openstack isn't the only opendev user | 16:36 |
| fungi | we had centos 7/8/9 simultaneously at one point | 16:36 |
| clarkb | and generally we keep the releases in place if they are still supported by upstream and people are using them | 16:36 |
| sean-k-mooney | oh ok ya in the openev contedt 8 can make sense | 16:36 |
| clarkb | and I think the release cadence overlap is such that 3 can be supported at the same time | 16:36 |
| sean-k-mooney | *context | 16:36 |
| sean-k-mooney | for open dev probably | 16:36 |
| sean-k-mooney | for openstack we only have 18 monts of supprot so we will never need more then 2 | 16:37 |
| frickler | the definition of the PTI for 2025.1 is due rather soon, so with neither images for centos 10 in opendev nor devstack support, this doesn't sound viable to me | 16:37 |
| fungi | generally we drop images when the versions go to end of free/public support | 16:37 |
| clarkb | and to be clear openstack is the number one "offender" of this drag out support thing | 16:37 |
| clarkb | so I don't think you should anticipate openstack rotating support that quickly either | 16:37 |
| clarkb | see also the massive tangle of xenial things in openstack | 16:37 |
| clarkb | (or things that were once openstack) | 16:38 |
| sean-k-mooney | frickler: so centos 10 support is deffintely somethign i want to see for 2025.1 as well as making ubuntu 24.04 required | 16:38 |
| fungi | i think openstack is in the position of caring less now, with only 2 years of actual maintenance for releases and everything older "unmaintained" so any testing is best-effort | 16:38 |
| sean-k-mooney | i proably should look at updating devstack/dib/project-config to enable that | 16:38 |
| clarkb | fungi: yes I think the issue is more that openstack doesn't do any of hte cleanup stuff | 16:38 |
| sean-k-mooney | ubuntu 24.04 is still my priority to have running in nova-next before the end of 2024.2 | 16:39 |
| fungi | right, and then when we go removing images, old branches end up in an error state | 16:39 |
| clarkb | I've been trying to psuh that as part of maintenance activity, but what generally happens is openstack says they don't care anymore and does minimal "cleanup" aka switch branch to unmaintained then I'm left holding the responsibility for cleaning things up a few years later | 16:39 |
| sean-k-mooney | clarkb: well from my point of vew when a branch goes to unmainted it should go to a tag | 16:40 |
| fungi | so yeah, i'm with you there, we don't need openstack caring less about old branches, we need openstack cleaning up old branches | 16:40 |
| sean-k-mooney | and only become a branch if the unmaintaiend team creates teh branch and fixes the ci as part of that | 16:40 |
| sean-k-mooney | we will be moving 2023.1 to unmaintianed soon | 16:41 |
| fungi | sean-k-mooney: that was one of the early proposals, but the model the tc settled on is that all stable/foo branches get one free cycle as unmaintained/foo before someone needs to confirm they intend to maintain them | 16:41 |
| fungi | s/maintain/care for/ | 16:41 |
| sean-k-mooney | ya i rememebr the disucssions | 16:42 |
| sean-k-mooney | there are pros and cons | 16:42 |
| sean-k-mooney | when the rename happens someone has to fix the jobs | 16:42 |
| fungi | i still think it should have been doable to start the conversation when stable/foo enters its last 6 months of maintenance, agreed | 16:42 |
| fungi | rather than waiting until after it gets renamed | 16:43 |
| fungi | well, not really renamed, but replaced | 16:43 |
| sean-k-mooney | ya we abandon all the openchanges and remove the stable branch and recreate the branch with the new name from the eol tag right | 16:43 |
| sean-k-mooney | but the mecahnicas are not that imporant form an external perspecitive its effectivly a rename | 16:44 |
| sean-k-mooney | i actully caught the replay of yesterdays? tc call where part of this was dicussed | 16:44 |
| fungi | yeah, point being it's rather a bit of additional work which could be avoided if the conversation/decision to care for the branch in unmaintained could start 6 months earlier | 16:44 |
| sean-k-mooney | i dont often watch the tc meeing recoding on youtube but i just happend to see it while cooking dinner | 16:46 |
| fungi | it's too late for 2023.1, but maybe when 2024.2 releases the tc can be convinced to immediately open invitations to care for unmaintained/2023.2 and then only create those branches where someone is opting into it in advance | 16:48 |
| fungi | that still gives prospective caretakers roughly 6 months to decide | 16:48 |
| fungi | as things stand right now, we're looking at a massive unmaintained/zed deletion next month | 16:50 |
| fungi | which we could in theory have avoided since most of them didn't get caretaker volunteers | 16:50 |
| opendevreview | Merged openstack/project-config master: Prep sunbeam single charm repos for retirement https://review.opendev.org/c/openstack/project-config/+/917827 | 16:56 |
| *** bauzas_ is now known as bauzas | 19:27 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!