| opendevreview | Merged openstack/kolla-ansible stable/yoga: venus: mark as broken as it was not released https://review.opendev.org/c/openstack/kolla-ansible/+/841152 | 07:03 |
|---|---|---|
| SvenKieske | does anyone here do something like an "sbom" (software bill of materials) for kolla-ansible containers? if so: which software do you use? would that be something for kolla to include itself? is the project interested in this stuff? | 07:10 |
| mnasiadka | SvenKieske: you mean a list of ALL installed packages? | 07:16 |
| mnasiadka | yoctozepto: it seems venus is not planning to do a Yoga release - should we revert the commits adding the functionality in stable/yoga? | 07:21 |
| yoctozepto | mnasiadka: oddly, it seems sensible given the circumstances; for sure need to drop CI as it will always fail ;/ | 07:24 |
| opendevreview | Michal Arbet proposed openstack/kolla master: Fix redis containers always reporting changed https://review.opendev.org/c/openstack/kolla/+/840954 | 07:40 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Fix redis_sentinel container restarts https://review.opendev.org/c/openstack/kolla-ansible/+/841219 | 07:43 |
| frickler | SvenKieske: we are working on that in the OSISM/SCS context, let me check if we have something viewable already | 07:43 |
| hrw | mnasiadka, yoctozepto, frickler: I want to propose one thing: if we get patch for fresh openstack/* project then "was it released at least once" is requirement. | 07:45 |
| hrw | patch can get polished before release and merge at the end of our cycle | 07:46 |
| mnasiadka | I think that was the initial plan, but then we tried to be friendly :) | 07:46 |
| frickler | hrw: well this is a bit of chicken and egg issue, people being able to test it might help with a release being created | 07:46 |
| mnasiadka | any volunteer to do the reverts? | 07:47 |
| hrw | frickler: 'git review -d; kolla-build' - we suggest using own images anyway | 07:47 |
| kevko | morning | 07:47 |
| kevko | anyone for this ? https://review.opendev.org/c/openstack/kolla/+/840954 ? very simple | 07:48 |
| frickler | hrw: that doesn't work for k-a. and with the amount of integration that e.g. osism uses, testing in-progress changes is non-trivial, too | 07:48 |
| hrw | true | 07:49 |
| frickler | for me, reverting when things don't work out, like we are about to do now, seems feasible | 07:49 |
| frickler | and I guess to support that I should volunteer to propose the reverts | 07:49 |
| frickler | mnasiadka: that's only for yoga, not in master, right? | 07:50 |
| hrw | and both kolla and kolla-ansible | 07:50 |
| mnasiadka | frickler: yup | 07:50 |
| hrw | frickler: 2db1201827654344e9b9b381192f4b7147ab8648 and 3d51f064646940ce5034489238120ab2a6752879 in kolla. And e5160fc4650cda1c39f93bb68136c633688eac2a in meantime | 07:50 |
| hrw | frickler: one is recent disablement, second adds venus, third is releasenotes polishing | 07:51 |
| SvenKieske | frickler: that sounds promising regarding OSISM :) | 07:53 |
| frickler | hrw: mnasiadka: can we still simply delete the venus reno for yoga or do we need to keep it and add a new one about the removal? | 08:03 |
| hrw | remove | 08:04 |
| hrw | keeping "added venus\nremoved venus as they did not delivered" is kind of shaming | 08:05 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: haproxy: support single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/823395 | 08:09 |
| opendevreview | Dr. Jens Harbott proposed openstack/kolla stable/yoga: Revert "venus: mark as unbuildable as it was not released" https://review.opendev.org/c/openstack/kolla/+/841227 | 08:10 |
| opendevreview | Dr. Jens Harbott proposed openstack/kolla stable/yoga: Revert "venus: add log management system" https://review.opendev.org/c/openstack/kolla/+/841228 | 08:10 |
| frickler | o.k., then I have this ^^ looking at k-a now | 08:10 |
| hrw | +2 on both | 08:15 |
| opendevreview | Dr. Jens Harbott proposed openstack/kolla-ansible stable/yoga: Revert "venus: mark as broken as it was not released" https://review.opendev.org/c/openstack/kolla-ansible/+/841230 | 08:18 |
| opendevreview | Dr. Jens Harbott proposed openstack/kolla-ansible stable/yoga: Revert "Move venus group to the correct inventory section" https://review.opendev.org/c/openstack/kolla-ansible/+/841231 | 08:18 |
| opendevreview | Dr. Jens Harbott proposed openstack/kolla-ansible stable/yoga: Revert "ADD venus for kolla-ansible" https://review.opendev.org/c/openstack/kolla-ansible/+/841232 | 08:18 |
| SvenKieske | can someone enlighten me: why does grafana in a kolla-ansible deployment from scratch always run "database migrations"? this shouldn't be necessary on a clean install, should it? I'm clearly missing something.. | 08:31 |
| hrw | maybe roles miss 'when' block | 08:34 |
| frickler | SvenKieske: I'm not sure what grafana does, but in general database "migrations" are also used to initially deploy the needed tables and schemes | 08:34 |
| SvenKieske | frickler, ah I see, meanwhile I found this "During startup, Grafana will automatically migrate the database schema (if there are changes or new tables)." here: https://grafana.com/docs/grafana/latest/installation/upgrading/ | 08:35 |
| SvenKieske | I guess a new install qualifies as "new tables". | 08:35 |
| frickler | yes, essentially it does a migration from "nothing there" to the expected state | 08:37 |
| frickler | most openstack services do their database deployment in the same way. from time to time these migrations are compacted, so that you don't have to go through every step since Austin | 08:38 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: WIP: Test haproxy single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/841239 | 08:52 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: WIP: Test haproxy single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/841239 | 09:03 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: WIP: Test haproxy single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/841239 | 09:12 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: WIP: Test haproxy single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/841239 | 09:22 |
| SvenKieske | we are hitting https://bugs.launchpad.net/kolla-ansible/+bug/1966606 during kolla-ansible deployment, apparently jinja v3.1.0 seems to be broken? is someone already aware of this? | 09:29 |
| hrw | SvenKieske: which branch? can you give 'git log -1' output (commit id is enough)? | 09:30 |
| hrw | SvenKieske: in March we did jinja update handling across branches. If your code is older than 24th March then please update | 09:32 |
| SvenKieske | still on stable/train (well internal fork with custom backports).. | 09:32 |
| hrw | train is EOL | 09:33 |
| SvenKieske | I seem to remember that we did pull that jinja update, but let me double check that.. | 09:33 |
| SvenKieske | hrw: yeah I know, we are preparing upgrades :).. | 09:33 |
| hrw | SvenKieske: https://review.opendev.org/c/openstack/kolla/+/835345 may help you | 09:34 |
| hrw | SvenKieske: it failed on zuul and as train is EOL I do not plan to refresh it | 09:34 |
| SvenKieske | thanks! will check it out (and we really net to get going on these upgrades..) | 09:35 |
| opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: [CI] Raise [keystone_authtoken]http_request_max_retries https://review.opendev.org/c/openstack/kolla-ansible/+/840901 | 09:35 |
| hrw | SvenKieske: go Xena at least | 09:35 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: WIP: Test haproxy single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/841239 | 09:36 |
| SvenKieske | hrw: I'm happy if I can get to victoria at least :D xena would be great | 09:36 |
| hrw | would say 'go Yoga' but people using EOL branches often fear new things | 09:36 |
| hrw | SvenKieske: Vicky gets EM/EOL "soon" | 09:37 |
| SvenKieske | hrw: I mean, to be honest: there are many broken things which people seem to not use (enough) so we have to double check everything if it works.. | 09:37 |
| hrw | SvenKieske: aware | 09:37 |
| SvenKieske | so that tends to get in the way of fast upgrades, sadly, but doing our best and try to contribute fixes upstream so it get's less painful over time :) | 09:37 |
| hrw | SvenKieske: but as you do update via several branches I suggest going as far as possible | 09:38 |
| hrw | SvenKieske: so you get ~2 years for next upgrade | 09:38 |
| hrw | SvenKieske: I started working on Kolla when we realized that wiping whole deployment and learning new way of doing it is cheaper than keeping what we had. Then next step was to teach coworkers how to submit patches/reports | 09:39 |
| SvenKieske | yeah, problem is supported base images and we want to use the same base image for our ceph deployment as well (which also needs to be upgraded) | 09:39 |
| SvenKieske | so figuring out which ubuntu release works good with hardware & openstack & ceph release & make sure that all needed features work & performance is good enough as well. and our team just shrank to 3 ppl :D | 09:40 |
| hrw | SvenKieske: go 20.04 then | 09:41 |
| hrw | SvenKieske: you get same base in kolla, can run Ceph N-P on it (iirc) | 09:42 |
| hrw | SvenKieske: and supported to 2025 so in 2 years you migrate to 22.04 | 09:42 |
| hrw | and use kolla Becky (or 2022.2) | 09:43 |
| frickler | itym 2023.2? | 09:45 |
| hrw | frickler: Xena in 2022h1, 2022.2/2023.1 in 2024h1 | 09:47 |
| hrw | or maybe even 2023.2 indeed | 09:47 |
| SvenKieske | hrw: that seems to be the plan for us :) | 09:58 |
| hrw | SvenKieske: migrating LTS->LTS requires imho 2 subreleases to make sure that canonical managed to fix most of migration bugs. so ~year after release | 10:00 |
| hrw | SvenKieske: so in 2022 you go to 20.04, 2023h2+ can go with 22.04 | 10:01 |
| opendevreview | Merged openstack/kolla stable/yoga: Revert "venus: mark as unbuildable as it was not released" https://review.opendev.org/c/openstack/kolla/+/841227 | 10:53 |
| opendevreview | Merged openstack/kolla stable/yoga: Revert "venus: add log management system" https://review.opendev.org/c/openstack/kolla/+/841228 | 11:16 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Revert "venus: mark as broken as it was not released" https://review.opendev.org/c/openstack/kolla-ansible/+/841230 | 11:20 |
| mnasiadka | any other reverts not merged yet? | 11:21 |
| frickler | mnasiadka: k-a still has 2 on top of ^^ | 11:29 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Revert "Move venus group to the correct inventory section" https://review.opendev.org/c/openstack/kolla-ansible/+/841231 | 11:32 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: haproxy: support single external frontend https://review.opendev.org/c/openstack/kolla-ansible/+/823395 | 11:53 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Revert "ADD venus for kolla-ansible" https://review.opendev.org/c/openstack/kolla-ansible/+/841232 | 12:17 |
| frickler | mnasiadka: this should have been the final one ^^ | 12:21 |
| mnasiadka | goodie | 12:24 |
| opendevreview | Michal Arbet proposed openstack/kolla stable/victoria: macros/pip: revert to old setuptools way https://review.opendev.org/c/openstack/kolla/+/841271 | 13:46 |
| opendevreview | Michal Arbet proposed openstack/kolla stable/victoria: macros/pip: revert to old setuptools way https://review.opendev.org/c/openstack/kolla/+/841271 | 13:49 |
| kevko | hrw: I was just rebuilding victoria and found issue with setuptools you've already fixed in xena an wallaby ...could you please review it as victoria is still extended maintanance ? | 13:52 |
| hrw | +2 | 13:53 |
| kevko | hrw: thanks | 13:53 |
| kevko | hrw: hmm, can I merge it if I backported ? :D | 13:56 |
| kevko | or no ? | 13:56 |
| kevko | that's was quick :) thanks frickler | 14:04 |
| frickler | kevko: thought I better releave you from that mental conflict ;) | 14:05 |
| kevko | frickler: hh, thanks .. if you have time you can check another tiny bugfix from today i proposed :) | 14:06 |
| kevko | frickler: https://review.opendev.org/q/topic:redis-restarts | 14:07 |
| opendevreview | Vladislav Belogrudov proposed openstack/kolla-ansible master: Fix Ansible errors if globals.yml is not modified https://review.opendev.org/c/openstack/kolla-ansible/+/839761 | 14:52 |
| opendevreview | Kyle Dean proposed openstack/kolla-ansible master: Put openstack exporter behind HAproxy https://review.opendev.org/c/openstack/kolla-ansible/+/841301 | 15:37 |
| opendevreview | Kyle Dean proposed openstack/kolla-ansible master: Put openstack exporter behind HAproxy so only one is queried at a time https://review.opendev.org/c/openstack/kolla-ansible/+/841301 | 15:41 |
| opendevreview | Merged openstack/kolla stable/victoria: macros/pip: revert to old setuptools way https://review.opendev.org/c/openstack/kolla/+/841271 | 16:17 |
| opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: [CI] Raise [keystone_authtoken]http_request_max_retries https://review.opendev.org/c/openstack/kolla-ansible/+/840901 | 17:16 |
| *** mazzy5098812929580859497 is now known as mazzy509881292958085949 | 23:29 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!