Wednesday, 2023-10-18

shyambHi Team, Is Antelope release done?07:57
shyambI see release notes of 2023.1 but I don't any mention of Antelope. https://docs.openstack.org/releasenotes/kolla/2023.1.html07:58
shyambAny quay.io also does not have any Antelope tagged container images07:58
shyambhttps://quay.io/repository/openstack.kolla/nova-api?tab=tags07:58
mnasiadka2023.1 is Antelope07:59
shyambOkay, thank you mnasiadka08:00
shyambLooks like we have changed naming strategy. 08:00
shyambAre we going to use this format going ahead?08:01
shyamb2023.1, 2023.208:01
mnasiadkashyamb: https://governance.openstack.org/tc/reference/release-naming.html08:01
shyambThank you mnasiadka. This is helpful.08:06
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: WIP: Check OVN DB schema on container update  https://review.opendev.org/c/openstack/kolla-ansible/+/89872108:38
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: WIP: Check OVN DB schema on container update  https://review.opendev.org/c/openstack/kolla-ansible/+/89872108:39
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: WIP: Check OVN DB schema on container update  https://review.opendev.org/c/openstack/kolla-ansible/+/89872110:06
guesswhat[m]Has anyone experience with rabbitmq optimalization for single node deployment? Sas that default value for erlang is 2:2, but it still peaks to 1000% CPU . Thanks11:41
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: WIP: Check OVN DB schema on container update  https://review.opendev.org/c/openstack/kolla-ansible/+/89872111:53
*** dimentor is now known as dimentor_11:53
*** mmalchuk is now known as dimentor11:53
*** dimentor is now known as mmalchuk11:59
*** dimentor_ is now known as dimentor12:00
opendevreviewAlex Welsh proposed openstack/kayobe master: Add seed_deploy_containers_registry_attempt_login  https://review.opendev.org/c/openstack/kayobe/+/89843712:10
mnasiadkamgoddard mnasiadka bbezak frickler kevko SvenKieske mmalchuk gkoper jangutter jsuazo - meeting in 612:54
SvenKieskeyay12:55
mmalchukyuhu12:55
* SvenKieske stumbles out of a total of 4:40 hours of meeting straight into the next one -.-12:56
* jangutter is hurtling towards the end of a quarter.12:59
mnasiadka#startmeeting kolla13:00
opendevmeetMeeting started Wed Oct 18 13:00:09 2023 UTC and is due to finish in 60 minutes.  The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot.13:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
opendevmeetThe meeting name has been set to 'kolla'13:00
mnasiadka#topic rollcall13:00
mmalchuko/13:00
jangutter\o13:00
mnasiadkao/13:01
SvenKieskeo/13:01
frickler\o13:01
mattcreeso/13:01
jsuazoo/13:01
mnasiadka#topic Agenda13:03
mnasiadka* Announcements13:03
mnasiadka* CI status13:03
mnasiadka* Release tasks13:03
mnasiadka* Current cycle planning13:03
mnasiadka* Additional agenda (from whiteboard)13:03
mnasiadka* Open discussion13:03
mnasiadka#topic Announcements13:03
mnasiadkaPTG is next week13:03
mnasiadka#link https://etherpad.opendev.org/p/kolla-caracal-ptg13:03
SvenKieske\o/13:04
mnasiadkaSign up please in L3713:04
* mmalchuk ready13:04
mnasiadkaAnd please add topics (L101 and beyond)13:04
mnasiadka#topic CI status13:04
mnasiadkaI think it's mainly green, not couting our Ansible breakage13:04
opendevreviewJuan Pablo Suazo proposed openstack/kolla-ansible master: Enable the Fluentd Plugin Systemd  https://review.opendev.org/c/openstack/kolla-ansible/+/87598313:04
opendevreviewJuan Pablo Suazo proposed openstack/kolla master: Adds TAAS Neutron plugin to support OVS port mirrors  https://review.opendev.org/c/openstack/kolla/+/88515113:04
mnasiadkaTrying to wrap my head around it, but it's not going to be an easy one13:04
mnasiadkaAnybody did have a look in that as well?13:05
fricklernot yet. maybe building a simple reproducer will be needed?13:05
SvenKieskenot really, I still suspect a real upstream bug, or did we change anything in that area?13:05
mnasiadkaWe did not, that's the usual "we fixed that bug in Ansible" :D13:06
mmalchukthere is an issue upstream, SvenKieske have a link?13:06
SvenKieskethere's also already user reports about this on the ML, I answered with the workaround13:06
SvenKieske#link https://github.com/ansible/ansible/issues/8194513:06
mmalchukright13:06
mnasiadkaAnyway, let's move on13:07
mnasiadka#topic Release tasks13:07
mnasiadkaTime to have a look at them - we merged switching the sources to Bobcat13:07
mnasiadkaseems still no sign of RDO repos on the centos stream mirror13:08
mnasiadkaI'll wait instead of using trunk.rdoproject.org13:08
opendevreviewDawud proposed openstack/kolla-ansible stable/yoga: Remove the `grafana` grafana  https://review.opendev.org/c/openstack/kolla-ansible/+/89873613:08
mnasiadkano other release tasks per se - just reviewing existing patches13:09
opendevreviewDawud proposed openstack/kolla-ansible stable/yoga: Remove the `grafana` volume  https://review.opendev.org/c/openstack/kolla-ansible/+/89873613:09
SvenKieskenot sure I can finish the fluentd stuff in time..currently have a problem checking stuff inside the container. I think it's best to split out fluentd out of the "common" role, which will require some more work.13:09
SvenKieskenot sure if I should move this point to "open discussion"?13:10
mmalchukgood idea to split13:10
mnasiadkait's ok to discuss it here13:10
mnasiadkawe should probably move this cycle13:11
mnasiadkabut it seems we don't have to13:11
SvenKieskeyeah, so if there are no objections I'd move fluentd in a dedicated role, I'm also on vacation friday and with PTG coming up..how much time is left? :D13:11
opendevreviewDawud proposed openstack/kolla-ansible stable/yoga: Remove the `grafana` volume  https://review.opendev.org/c/openstack/kolla-ansible/+/89873613:12
SvenKieskeI guess I take the id software dev approach: "It's done, when it's done".13:12
mnasiadkait doesn't need to be done before the PTG13:13
mnasiadkawe're cycle trailing, so we still have some time to release13:13
mnasiadkaalthough I would prefer we do it sooner than last minute :)13:13
frickleris fluentd the only upgrade missing? I lost track, are we good with prometheus plugins?13:14
SvenKieskeyeah sure; I just need to do some other stuff as well - mainly writing docs it seems - will check internally what has higher priority, maybe the answer is even fluentd.13:14
mmalchukor yesterday)13:14
SvenKieskeafaik I asked last - or the meeting before that - if someone could take a look at the prometheus plugins, no? I have lost track as well.13:15
mnasiadkaThat might be looked into even last minute, although I would prefer that we would finally have a proper solution (I remember hrw started a script for checking versions on github and updating sources.py)13:15
mnasiadkaI might have a look into that after that crappy Ansible breakage13:16
mnasiadkaok then13:17
mnasiadkaPodman - seems it's waiting for some reviews, probably mine13:18
mnasiadkaLet's Encrypt the same13:18
mnasiadkafrickler: do you have any cycles for looking at those two?13:18
SvenKieskehttps://github.com/openstack-exporter/openstack-exporter/releases is at least at the latest :)13:18
mnasiadkaIt would be nice to merge them this cycle13:18
fricklerI can check podman13:18
SvenKieskebe sure to also look at the (linked?) ansible-collection-kolla change for podman, I guess that's also still open13:19
fricklerack13:20
SvenKieskeah it's in the depends on: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/85224013:20
mmalchukhttps://review.opendev.org/c/openstack/kolla/+/887347 can be merged13:20
mnasiadkaI commented on ack patch - I think we need podman based jobs there13:20
mnasiadkaa-c-k it is13:20
SvenKieskeyeah, I agree, there should be some testing going on :)13:21
mnasiadkaOk, Let's Encrypt - I'll ask bbezak to review those next week13:21
mnasiadkaand let's try to get those in, even if the code is not perfect-ish ;)13:21
mnasiadka#topic Additional agenda13:22
mnasiadka4 patches from jsuazo (the same ones again)13:22
mnasiadkalet's see13:22
mnasiadkahttps://review.opendev.org/c/openstack/kolla/+/88515113:22
mnasiadka+2 from me13:22
mnasiadkahttps://review.opendev.org/c/openstack/kolla-ansible/+/88541713:23
mnasiadka(k-a side of TAAS)13:23
mnasiadkaalready has +2 from me13:23
mnasiadkafrickler: willing to have a look or should wait for bbezak?13:23
fricklerbetter ask bbezak, I'd be too picky for this13:24
mnasiadkaunderstood13:24
mnasiadkahttps://review.opendev.org/c/openstack/kolla-ansible/+/844614 - Glance/Cinder-backup S313:24
mmalchukready 2 weeks ago13:25
mnasiadkacommented, but basically looks good13:26
mnasiadkaok then13:26
mnasiadkanothing more on the whiteboard13:26
mnasiadka#topic Open discussion13:26
mnasiadkaI'll cancel next weeks meeting because we'll have the PTG sessions13:27
mnasiadkaAnything else?13:27
SvenKieskeif someone has free time, and it's maybe also a topic for PTG: https://review.opendev.org/c/openstack/kolla-ansible/+/89854313:27
SvenKieskejust a hack to enable quorum queues; all the feedback I read was that they are really nice to have13:28
mmalchukinteresting. is this tested under heavy load?13:30
mnasiadkawell, the questions I have is 1) do we test that in CI 2) do we want to switch it to default in C 3) Migration docs for users - since it's breaking-ish13:30
mnasiadkabut since classic queue mirroring is deprecated for removal in 4.0 - it's either quorum queues or streams13:31
mnasiadkaSeems there is some movement in oslo.messaging13:31
mnasiadka#link https://review.opendev.org/c/openstack/oslo.messaging/+/88847913:31
mmalchuk2 - no13:31
SvenKieskemmalchuk: untested from my side (the patchset), from what I understand OVH does use quorum queues under heavy load, but they don't use k-a13:31
mmalchukthis enough, so we need this in k-a13:31
fricklerwe can start with adding the flag and allow this for new deployments. migration can be done next cycle then13:31
SvenKieskeno docs yet :) there's also an open bug to enable streams from OVH, but afaik that's not even implemented in oslo13:31
mnasiadka#link https://review.opendev.org/c/openstack/oslo.messaging/+/89082513:31
SvenKieskefrickler: that was my intention as well :)13:31
mmalchukfrickler +113:31
SvenKieskesimilar to what we did with the HA flag for rabbit13:32
mnasiadkafrickler: would feel safer if we had at least one CI job that uses it13:32
SvenKieskeI agree on the CI job, didn't have an immediate idea how that would best be implemented13:32
fricklerI don't think we need to test all possible configuration combinations. having a job when we switch the default is good enough IMO13:32
mmalchukmnasiadka test ha flag or +queues?13:32
mnasiadkaquorum queues13:32
opendevreviewDawud proposed openstack/kolla-ansible stable/yoga: Remove the `grafana` volume  https://review.opendev.org/c/openstack/kolla-ansible/+/89873613:33
mnasiadkawe don't need to test all possible configuration combinations, but it would be useful to test this - with a vision that we'll move to this as default since queue mirroring will be gone in RMQ 4.013:35
mnasiadkalike let's use quorum on Ubuntu and HA on Rocky - or something similar13:35
SvenKieskesure; would that just entail a set of jobs with it enabled? but which scenario should this run? I've never written upstream CI jobs "from scratch" so I would be grateful for some pointers how that should look like13:36
fricklerI would still prefer to defer that to the next cycle. but feel free to add a patch for that on top of SvenKieske's, it shouldn't block that change though13:36
SvenKieskeI can see both sides of the argument13:37
SvenKieskeI can add a warning doc "this is untested" :D on the other hand, when I looked at other deployment projects, they enabled quorum queues without additional tests ;)13:37
mmalchukyou said OVH uses it13:38
SvenKieske¯\_(ツ)_/¯13:38
SvenKieskethey don't use k-a13:38
mnasiadkaI can see people raising bugs about it and if we can't test it in CI - and no one uses that in production from the Kolla community - we're kind of not supporting it? :)13:38
mmalchukk-a only deployment tool13:38
SvenKieskeif you search for quorum queues on the ML there are some happy users :)13:38
fricklerto have some real testing, one would at least need to do upgrades, if not host failovers. for upgrades we need to add the flag now so we can test next cycle13:39
mmalchuktwo cents not enable it by default13:39
SvenKieskefwiw the SCS project is interested in quorum queues because there was some perceived instability in certain upgrade scenarios, so I hope I get some testers there as well13:39
mnasiadkanot enable it by default just yet13:40
SvenKieskemmalchuk: the current patch disables it13:40
mnasiadkajust have a minimal testing coverage13:40
SvenKieskefrickler: agree13:40
SvenKieskeokay, so a basic (HA?) job that just tests if enabling the flags works?13:40
mnasiadkawell, I guess multinode would be best13:41
SvenKieskeseems like a good compromise?13:41
mnasiadkabut singlenode would at least tell us it works13:41
mnasiadka:)13:41
SvenKieskeyeah multinode, that's what I meant13:41
mnasiadkabecause now we can only assume it works13:41
mnasiadkaOk, I'll think of something13:42
SvenKieskeit should work ;) it's at least supported by oslo :D I'll add some very basic test, probably not this week, so if someone beats me, I'm also fine with that :)13:42
mnasiadkaNot counting we just changed the default to HA13:42
mnasiadkaand mattcrees spent some time to enable it in upgrade jobs including a cleanup ;)13:42
mnasiadkaand probably moving from HA to quorum includes the same dance13:42
SvenKieskeyeah, it's a little different, but in practice you have to recreate all the queues.13:43
jangutterwhat about adding it to the "experimental" pipeline for now? Won't guarantee it won't regress, but at least that way the job lives in the repo.13:43
mnasiadkaor switch multinode (not multinode-upgrade) to quorum queues and fix the upgrade bit in C13:43
mnasiadkathis way we will have some better testing coverage and a path forward13:44
SvenKieskelet's discuss further stuff in the patch review, what do you think?13:44
mnasiadkabut anyway, we've spent too much time on this :)13:44
mnasiadkayes, let's discuss there13:44
* kevko is upgrading to zed right now, but watching 13:44
opendevreviewMerged openstack/kayobe stable/2023.1: bifrost: Populate bifrost host vars on deprovision  https://review.opendev.org/c/openstack/kayobe/+/89856113:44
mnasiadkaok then13:45
mnasiadkaI don't think there is anything more13:45
mmalchukwe still lack of Kayobe reviews13:45
mmalchukhttps://review.opendev.org/c/openstack/kayobe/+/86139713:46
mmalchukand https://review.opendev.org/c/openstack/kayobe/+/87955413:46
mmalchuka half of year13:46
mmalchukalmost13:46
mnasiadkaPassed that internally in SHPC13:46
mmalchukthanks13:47
mnasiadkaLet's finish for today - thank you all for coming and speak to you on Monday :)13:47
mnasiadka#endmeeting13:47
opendevmeetMeeting ended Wed Oct 18 13:47:21 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:47
opendevmeetMinutes:        https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-10-18-13.00.html13:47
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-10-18-13.00.txt13:47
opendevmeetLog:            https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-10-18-13.00.log.html13:47
mmalchukthanks mnasiadka 13:47
SvenKieskeyeah, thanks13:47
opendevreviewAlex Welsh proposed openstack/kayobe master: Add seed_deploy_containers_registry_attempt_login  https://review.opendev.org/c/openstack/kayobe/+/89843713:59
mnasiadkaSvenKieske, frickler: what about adding the magnum CAPI plugin to Kolla images? Are you going to push that patch? Would be nice for users14:00
guesswhat[m]mnasiadka: You still need the CAPI enabled K8s cluster14:16
guesswhat[m]Its not standalone14:16
mnasiadkaguesswhat[m]: thank you captain obvious14:18
kevko:D 14:20
guesswhat[m]Why to include then? Or does the Kolla team wanting to switch finally to the K8s orchstration ?14:23
mnasiadkaguesswhat[m]: And that's why we would like to have the Magnum driver included? lol14:35
mnasiadkaif you like Kubernetes too much - there's openstack-helm14:35
guesswhat[m]CAPI plugin for Magnum is integrated in https://github.com/vexxhost/atmosphere, which is K8s based Openstack deployment14:42
mnasiadkaWhich uses openstack-helm under the hood14:43
fricklerdidn't we have the same discussion almost word by word two weeks ago? but also I don't have any interest in k8s, so far at least14:54
opendevreviewPierre Riteau proposed openstack/kolla-ansible master: CI: Log details about failed containers  https://review.opendev.org/c/openstack/kolla-ansible/+/89248816:39
mdboothHello! I'm trying to install with kolla for the first time. My deployment host is Fedora, deploying an all-in-one on another host which is CentOS9. Kolla is installed in a python3.9 venv (first try was default python: 3.11, same issue). I've installed kolla stable/2023.1 in the venv. It's dying with:18:14
mdboothTASK [nova-cell : Extract current cell settings from list] fatal: [nimbus-01]: FAILED! => {"msg": "template error while templating string: Could not load \"extract_cell\": 'extract_cell'. String: {{ existing18:15
mdboothLet me try that again...18:15
mdboothTASK [nova-cell : Extract current cell settings from list] 18:15
mdboothfatal: [nimbus-01]: FAILED! => {"msg": "template error while templating string: Could not load \"extract_cell\": 'extract_cell'. String: {{ existing_cells_list | extract_cell(nova_cell_name) }}. Could not load \"extract_cell\": 'extract_cell'"}18:15
mdboothI'm guessing that means it's not finding the filter 'extract_cell'? I have never used an ansible custom filter before, so I'm not sure how it's supposed to be loaded. AFACT the function is present in the venv.18:17
mdboothThe deployment host is different to the target host. Is that unusual?18:24
mdboothSystem python on the target is 3.918:29
fricklermdbooth: bug in latest ansible-core, try using the previous version. I think 2.4.10 rather than .1118:30
mdboothfrickler: Will try that, thanks!18:31
mdboothfrickler: I think that worked. Many thanks!18:40

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