Thursday, 2023-06-15

opendevreviewDr. Jens Harbott proposed openstack/kolla-ansible master: DNM: CI test  https://review.opendev.org/c/openstack/kolla-ansible/+/88615905:05
opendevreviewMaksim Malchuk proposed openstack/kolla master: Fix Venus containers built from correct branch  https://review.opendev.org/c/openstack/kolla/+/88596707:32
opendevreviewMaksim Malchuk proposed openstack/kolla master: config: switch OpenStack release back to master  https://review.opendev.org/c/openstack/kolla/+/88608707:33
* SvenKieske is thinking about if we can't just fork https://github.com/rabbitmq/erlang-debian-package and get some ARM Builders from openinfra side.09:05
dswebbquick question, has anyone else reported issues regarding galera SST transfers?  We've got an existing yoga cluster on rocky 8 that we're trying to move to rocky 9 in prep for the zed upgrades.  But on trying to deprecate a controller, rebuild on rocky 9 we keep getting timeouts on SST transfers.  same error as this ticket really: https://bugs.launchpad.net/kolla-ansible/+bug/2002465.  Connectivity is there, socat starts but 09:52
dswebbnothing happens.other controllers see the node trying to join the cluster.09:52
dswebbWSREP_SST: [ERROR] Possible timeout in receiving first data from donor in gtid stage: exit codes: 124 0 (20230615 09:38:32.603)09:52
dswebbsooo, I have an idea what the problem is:10:45
dswebblsof10:45
dswebbso the kolla project changed the healthcheck for ovsdb stop using lsof as it didn't work in containers10:49
dswebb(in rocky 9)10:49
dswebbhttps://github.com/openstack/kolla-ansible/commit/67607c679e20adaa42bc5271110a6b0aa992ffc810:55
dswebb100% that was the issue.  once we backported those values into the yoga branch of kolla-ansible SST worked like a charm11:01
dswebb(we were using the 14.8.0 pip package which didn't have those values)11:06
SvenKieskedswebb: here is the backport for that stuff in yoga: https://review.opendev.org/c/openstack/kolla-ansible/+/864920 (merged) it's always good to check if fixes are already on your prod branch and update from there :)11:59
dswebbyeah, it was an oversight on our side as we use pip for installation and forgot about the fix we had to do for ovsdb.  Probably worth releasing another pip release for yoga for those people who are trying to upgrade to zed12:03
SvenKieskemy advice would be to always build your own stuff from source12:08
SvenKieskemhm, I see, the last release is this one you mean? https://pypi.org/project/kolla/15.1.0/12:10
dswebbno, yoga release of kolla ansible12:11
dswebbso the 14.X release tags12:11
SvenKieskeI never use the version numbers and have to look up the matching :D12:11
dswebbhttps://docs.openstack.org/releasenotes/kolla-ansible/yoga.html12:12
dswebbwe're gonna make the move to stable/XXX branch12:12
SvenKieskehttps://pypi.org/project/kolla-ansible/14.8.0/ is some days newer than the above merged fix? doesn't it contain the fix?12:12
dswebbI was just going based on the 14.8.0 tag in github12:13
SvenKieskeyeah, I just use the stable branches, not sure the point in time releases are even recommended12:13
dswebbhttps://github.com/openstack/kolla-ansible/blob/14.8.0/ansible/group_vars/all.yml#L16412:13
dswebbwe always used the point in time releases for legacy reasons really.  that and it was easy to tell once a branch went out of release candidate to full release12:15
SvenKieskeat least you are on non EM branches, so could be worse :)12:18
mnasiadkaTalking about EM - it’s probably time to EOL W/X - unless we have people willing to maintain them.15:46
fricklermuch willingness to EOL from me ;)15:51

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!