Wednesday, 2022-06-01

opendevreviewJames Kirsch proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs  https://review.opendev.org/c/openstack/kolla-ansible/+/74134003:20
manohar_joshiHello everyone 08:11
opendevreviewPiotr Parczewski proposed openstack/kolla master: WIP: Add Opensearch image(s)  https://review.opendev.org/c/openstack/kolla/+/83037308:38
kevkomorning \o/08:51
guesswhatHello, Guys, I need help with Octavia, still can not get it work.. Anyone is willing to help me? Thanks10:10
hrwmorning10:11
hrwlibvirt--10:11
opendevreviewMark Goddard proposed openstack/kolla-ansible stable/yoga: Improve MariaDB restore procedure  https://review.opendev.org/c/openstack/kolla-ansible/+/84419710:11
opendevreviewMark Goddard proposed openstack/kolla-ansible stable/xena: Improve MariaDB restore procedure  https://review.opendev.org/c/openstack/kolla-ansible/+/84419810:11
opendevreviewMark Goddard proposed openstack/kolla-ansible stable/wallaby: Improve MariaDB restore procedure  https://review.opendev.org/c/openstack/kolla-ansible/+/84419910:11
hrwI am creating new VM and it fails with "Could not open '/var/lib/libvirt/qemu/nvram/debian11_VARS.fd': Permission denied" while file is 0666 and anyone can read it10:11
hrwhm. apparmor... 10:13
hrwheh. 5.17.0-3 recommends it10:14
mnasiadkaok, horizon for python 3.10 is broken, so Ubuntu Jammy is a bit stalled10:24
mgoddardmnasiadka: but otherwise working?10:29
hrwmnasiadka: yay10:33
guesswhatGuys, I am using this configuration https://pastebin.com/raw/62YfiuGZ ( netplan + globals.yaml ), but controllers can not reach octavia management network. I am following official docs for kolla/octavia https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html  any idea? Thanks10:45
mnasiadkamgoddard: otherwise seems ok10:54
guesswhatWhat is the purpose of octavia_network_interface and octavia_network_interface_address ? I tried to set octavia_network_interface_address to IP from octavia mngmnt network, also added IP to NIC assigned to management network, but still getting: Destination Host Unreachable, octavia_network_interface  adds interface to openvswitch and11:12
guesswhatoctavia_network_interface_address  should set correct IP if there is more then one IP, right?11:12
opendevreviewMichal Arbet proposed openstack/kolla-ansible master: Add proxysql support for database  https://review.opendev.org/c/openstack/kolla-ansible/+/77021511:16
opendevreviewMichal Arbet proposed openstack/kolla-ansible master: Edit services roles to support database sharding  https://review.opendev.org/c/openstack/kolla-ansible/+/77021611:16
opendevreviewMichal Arbet proposed openstack/kolla-ansible master: [CI] Test ProxySQL with shards in the nova cells scenario  https://review.opendev.org/c/openstack/kolla-ansible/+/77062111:17
opendevreviewMichal Arbet proposed openstack/kolla-ansible master: [DNM] Trigger cells job  https://review.opendev.org/c/openstack/kolla-ansible/+/83891611:17
kevkoguesswhat: IP for octavia has to be from octavia subnet range defined in openstack 11:17
kevkoit is for worker and healthmanager to be able contact amphorae instances11:17
guesswhatkevko: yes, but how is routing done for worker and octavia to be able to reach octavia mngmnt network?11:18
guesswhat*healthmanager11:18
kevkoif you have octavia_auto_configure everything is done 11:21
guesswhatthats not true11:21
guesswhatcreating loadbalancer fais, coz controller ( worker, healthmanager ) can not reach loadbalancer11:22
guesswhat*fails11:22
guesswhatthats why i am asking here for 3 days already, docs are misleading...11:22
kevkoare u using auto_configure ? 11:23
guesswhatof course, its the default option11:24
kevkohmm, i don't ....i just checked code 11:25
guesswhathttps://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/group_vars/all.yml#L120211:25
kevkoi have simple virtualized env ...so i have just physnet2:br-ex2 in neutron 11:25
kevkoand then i have port inserted into br-ex2 11:26
guesswhatmanually?11:26
kevkonope 11:26
hrwAn exception occurred during task execution. To see the full traceback, use -vvv. The error was: jinja2.exceptions.TemplateRuntimeError: No filter named 'kolla_address' found.11:26
hrwwe have too many extra steps to check in docs11:26
kevkoneutron_bridge_name: "br-ex,br-ex2"   neutron_external_interface: "external,octavia"    these two i have in globals ...11:27
kevkobut as I said ..i have virtualized environment where i have several interfaces ..11:27
hrw"ansible-galaxy collection install -r requirements.yml" did not covered that one. 'install-deps' dir11:27
hrwnops11:28
kevkohrw: kolla_address is filter inseide kolla-ansible ..could you import it in python ? 11:28
guesswhatkevko: i have also virtualized env... i tried the same, everything else related to octavia is default?11:28
guesswhatand br-ex2/octavia interface is just a network between controllers?11:29
kevkoguesswhat: don't know how auto_configure working ..i know it only from a code ..but you need that two values so neutron will create two bridges and insert ports into that bridges ...and then you need to create flavor, image, network, security groups in service project .. include into octavia conf ..and reconfigure octavia,neutron11:30
guesswhatI would like to see Yours globals.yaml file11:31
guesswhatAre You using ubuntu ?11:31
guesswhatnetplan + globals.yaml will help me to understand where is the difference11:31
guesswhatdid you touched octavia_amp_network ?11:32
kevkoguesswhat: https://paste.opendev.org/show/bIZLT1B3e0uplSVRFrq1/11:33
kevkothis will help you i think11:33
kevkoguesswhat: as i said i have virtualized environment so i can have as much interfaces as i want .... so i have octavia interface from outside L2 network which is in br-ex2 physnet2, and from same L2 network interface i have octavia-healthmanager interface where IP is bind 11:35
guesswhatkevko: thanks and has that L2 gateway? and do you have disabled gateway in lb-mgmt-net network?11:36
guesswhat*L2 network11:36
kevkoso octavia-healthmanager interface is accessible :   octavia-healthmanager <- same-physical-network-outside -> octavia -> br-ex2 -> PORTS of amphoraes 11:36
guesswhati am using also virtualized env, so another NIC is not a problem,  I just don't know, how to plug it correctly, if its just a trunk vlan plugged to the switch, or if it can be a be plugged to the router ...11:38
kevkoguesswhat: i have script for resources create 11:38
kevkoguesswhat: https://paste.opendev.org/show/bVMUbysW5mVR23LOSPzB/11:38
hrwkevko: uninstalled k-a, updated requirements, installed, works ;d11:39
kevkohrw: \o/ :) 11:39
guesswhatkevko, thanks ! so its external,  flat network ( where is available dhcp server ) and octavia management network is directly visible via that physnet211:43
guesswhat*external dhcp, and external L2 without gateway11:44
guesswhatcorrect?11:44
kevkoguesswhat: point is that interface which has IP from network subnet defined in openstack can reach instance created in that network ...so you need to create bridge where you will insert this l2 network ..or you have to route somehow 11:44
guesswhatyes, i was confused by this https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/octavia/tasks/hm-interface.yml, but thats working proly only for linuxbrdige11:45
kevkoguesswhat: yeah, that's the trick ..that i have two interfaces from same L2 inserted into my VM ..and then one port is inserted to br-ex2 and another port i'm listening from range defined in openstack 11:46
kevkoso it's directly accessible 11:46
kevkoi have dhcp enabled ...so i have dhcp-agents insert openstack ..i'm just changing pool and excluding IPs i gave to controllers which are listening .... 11:48
kevko*inseide11:48
kevko*inside11:48
guesswhatdidnt you try to use vlan instead of flat ?11:49
kevkodidn't 11:57
hrw./tools/init-runonce and can check what is wrong12:01
hrw2022-06-01 14:02:46.440 7 ERROR nova.compute.manager [instance: 7313f4d0-a7a0-4bf3-812b-680b5eb666f4] nova.exception.UEFINotSupported: UEFI is not supported12:03
hrwmeh12:04
* hrw out12:05
opendevreviewDr. Jens Harbott proposed openstack/kolla master: Add documentation to create monthly stable releases  https://review.opendev.org/c/openstack/kolla/+/84428612:22
guesswhatkevko: cz?13:17
kevkoguesswhat: yeah 13:28
opendevreviewMerged openstack/kolla-ansible master: Do not use keystone_admin_url et al  https://review.opendev.org/c/openstack/kolla-ansible/+/84372713:30
guesswhatkevko: PM13:46
kevkoguesswhat: replied :D 13:55
mnasiadka#startmeeting kolla14:00
opendevmeetMeeting started Wed Jun  1 14:00:52 2022 UTC and is due to finish in 60 minutes.  The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'kolla'14:00
fricklermnasiadka: meeting time?14:00
fricklerha, jinx14:01
fricklero/14:01
yoctozeptoo/14:01
mgoddard\o14:01
mnasiadka#topic rollcall14:01
mnasiadkanow you can repeat ;-)14:01
mnasiadkao/14:01
mmalchukhi14:01
yoctozeptolet's move on mnasiadka14:03
mnasiadka#topic agenda14:03
mnasiadka* Announcements14:03
mnasiadka* Review action items from the last meeting14:03
mnasiadka* CI status14:03
mnasiadka* Release tasks14:03
mnasiadka* Current cycle planning14:03
mnasiadka* Additional agenda (from whiteboard)14:03
mnasiadka* Open discussion14:03
mnasiadka#topic Announcements14:03
mnasiadkaOpenInfra Summit next week - but you know that14:03
mnasiadka#topic Review action items from the last meeting14:04
mnasiadkalet's check14:04
frickler#link https://grafana.opendev.org/d/c0d59dad13/kolla-failure-rate?orgId=114:04
fricklerstill waiting on feedback whether to add more jobs or less. also maybe second page for arm jobs?14:04
mnasiadkafrickler update grafana dashboard14:04
mnasiadkahrw to look for aarch64 failures in yoga/master14:04
mnasiadkahrw to look for aarch64 failures in yoga/master14:04
mnasiadkafrickler add a mention of doing monthly point releases for stable branches in kolla meetings docs page14:04
mnasiadkamnasiadka add more release liasons14:04
frickleralso https://review.opendev.org/c/openstack/kolla/+/844286 with questions for the stable releases14:05
mnasiadkafrickler: Ceph jobs failure rates?14:05
fricklermnasiadka: sure, just tell me what to add14:05
fricklerceph came to my mind, too14:05
yoctozeptofailure rates most of the time at 100% do not sound well and it's not true14:06
fricklerregarding aarch I did a look too, seems debian has updated qemu which is broken14:06
yoctozeptoI don't think this gives the right perspective14:06
frickleryoctozepto: which ones are you talking about?14:07
yoctozeptofrickler: kolla-ansible-ubuntu-source14:08
mnasiadkawell, all of the graphs show 100% failure rate from time to time14:08
mnasiadkaor are these not percent?14:08
yoctozeptoI mean, we probably need a different timewindow14:08
yoctozeptoso as not to get one failed jobs create a spike to 100%14:09
yoctozeptoit's nice to have the graphs but I struggle with their interpretation14:09
frickleriirc the timeframe is 24h, so if there is only one job per day (periodic), it's either 100% or 0%. I'll see if that can be increased to a week or so14:10
mnasiadkaeven if you go to 6 months time window - these are still spikes to 100%14:11
mnasiadkahttps://grafana.opendev.org/d/c0d59dad13/kolla-failure-rate?orgId=1&viewPanel=4&from=now-6M&to=now14:11
fricklerthe calculation still looks at 24h intervals14:11
mnasiadkaright14:11
fricklerhttps://opendev.org/openstack/project-config/src/branch/master/grafana/kolla.yaml#L3614:11
fricklermovingAverage(...'24hours')14:12
fricklerI'll try to change that14:12
mnasiadkaok, anyway - we need to be able to see some benefit in those dashboards14:12
mnasiadkabut thanks for working on them14:12
mnasiadka#action frickler to continue working on Grafana dashboards14:12
fricklermaybe once we no longer have large incidents every couple of days, things will look better14:13
mnasiadkahrw is absent, what about those master/yoga failures, are those fixed?14:13
fricklerno, aarch debian is completely broken with their qemu update14:13
yoctozeptoyeah, whatever happened14:13
yoctozeptocirros did not adapt14:13
yoctozeptoI heard ubuntu worked14:13
fricklerwe can either test with ubuntu cloud image instead of cirros or discuss whether we can use older qemu from not -backports14:14
frickleror somebody can tell me what I need to change in cirros14:14
mnasiadkaok, so it's still in progress14:14
fricklerI tested with newer kernel and grub, that didn't help14:14
mnasiadka#action hrw to look for aarch64 failures in yoga/master14:14
mnasiadkafrickler add a mention of doing monthly point releases for stable branches in kolla meetings docs page - I've seen a patch in progress with comments14:15
frickler#link https://review.opendev.org/c/openstack/kolla/+/844286 14:15
frickleronce those questions are answered, I can also create the release patch(es)14:16
mnasiadkacommented14:16
mnasiadkalet's go on14:16
mnasiadkaI haven't requested more releases liaisons14:16
mnasiadka#action mnasiadka add more release liasons14:16
mnasiadka#topic CI status14:17
yoctozeptogreen after yet another emergency weekend14:17
mnasiadkafantastic14:17
yoctozeptothankfully, me and frickler seem to be workaholics :-)14:17
mnasiadka#topic Release tasks14:17
mmalchukend me)14:18
mmalchukand me)14:18
mnasiadkaR-18 - nothing on our radar I guess14:18
mnasiadkaThere was somebody on the list complaining about Kolla 14.0.0 failing to build Ubuntu14:18
mnasiadkaDid we fix that and should release 14.0.1?14:18
yoctozeptommalchuk: :-)14:19
yoctozeptomnasiadka: frickler will release14:19
yoctozeptoI mean14:19
yoctozeptopropose 14:19
yoctozeptowe fixed that indeed14:19
mnasiadkaok14:19
mnasiadkafrickler: happy to follow the process we agree to and post new point releases for Yoga?14:20
priteauI've replied, they confirmed that it is fixed14:20
fricklerfrickler: well I'd propose stable releases for all branches in one go was my idea14:20
fricklerehm ... mnasiadka:14:21
yoctozeptoyoctozepto: that's a good idea14:21
yoctozeptoyoctozepto: thank you14:21
yoctozepto:D14:21
mnasiadkayeah, in one go - sorry ;-)14:21
mnasiadka#topic Current cycle planning14:21
mnasiadkaUbuntu 22.04 LTS is moving forward-ish - Horizon is broken for Python 3.10 (https://review.opendev.org/c/openstack/horizon/+/830618), MariaDB is broken-ish (but workarounded for now)14:23
yoctozeptowhat's wrong with mariadb?14:24
yoctozepto(just curious)14:24
mnasiadkahttps://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/197063414:25
mnasiadkafix is out, but in kinetic-proposed14:25
mnasiadka(and we're using mariadb packages from Ubuntu repo for now, because upstream MariaDB hasn't built those yet)14:25
mnasiadkaAnything on other priorities?14:27
yoctozeptothe solution is "disable lto" nice14:27
yoctozeptoso much for optimisations14:27
yoctozepto:D14:27
mnasiadkahttps://etherpad.opendev.org/p/KollaWhiteBoard - L28914:27
yoctozeptomnasiadka: I guess we should discuss letsencrypt14:27
yoctozeptoI posted some comments there14:27
yoctozeptoplease check them out14:27
mnasiadkayoctozepto: yeah well, tell me why mariadb checks kernel version ;-)14:28
yoctozepto(I have as I promised to do it May :D )14:28
mnasiadkaok, I'll try to look into it - mgoddard got some cycles to look there as well?14:28
mgoddardyeah, should do14:29
mnasiadkaso let's try to focus on getting this in finally, then we can look at podman14:29
mnasiadka#topic Additional agenda (from whiteboard)14:30
mnasiadka(yoctozepto) https://review.opendev.org/c/openstack/kolla/+/843751/14:30
yoctozeptokevko will also want his proxysql in14:30
yoctozeptowe merged the first part14:30
yoctozeptoand regarding that patch posted by mnasiadka:14:31
yoctozeptohow do we go about removing the admin endpoints?14:31
yoctozeptowe did not in yoga, we are leaving users with admin endpoints14:31
yoctozeptofor keystone it matters what this points to but we don't have any strategy atm to apply14:31
yoctozeptothat's what needs discussion14:32
fricklerI would leave it to deployers to decide when to clean up14:32
mmalchukagree14:33
fricklerand it doesn't hurt if they decide not to do it at all14:33
yoctozeptoworks for me14:33
mnasiadkacase solved I guess14:34
yoctozeptobut there is a discussion with mgoddard that he wants it differently14:34
yoctozeptolet me find that14:34
yoctozeptohttps://review.opendev.org/c/openstack/kolla-ansible/+/84089814:34
mnasiadkawell, we have been removing endpoints in the past (like cinderv2)14:34
mgoddardI'd prefer that upgraded systems look like fresh deploys, where possible & sensible14:35
mgoddardwhat's the argument for leaving the admin endpoints?14:35
yoctozeptoyeah, so maybe do it again and be gone with that extra unused endpoint?14:35
yoctozeptomgoddard: I guess the argument is us being lazy - it's still a valid argument!14:35
yoctozepto:D14:35
fricklerthat patch is about changing the URL for the keystone admin endpoint, that's a different thing14:36
yoctozeptofrickler: well, different but very much related14:36
yoctozeptoupdate or remove14:36
yoctozeptothat is the question14:36
yoctozeptoand I guess then we should remove all admin endpoints14:37
fricklerfor the other service's admin endpoints, the URL is the same as internal iirc. so they will continue to work14:37
yoctozeptobtw, is the keystone admin endpoint still used anywhere? maybe we should run tempest soon to discover this ;d14:37
fricklerfor the different port, we want to cleanup haproxy so it will no longer work14:37
mmalchukyoctozepto: but we'r lazy)14:37
tibeer@frickler is that something for ra-rau or me?14:37
yoctozeptofrickler: I agree with mgoddard that it's better to clean up14:38
mgoddardagree with frickler, they are fairly different things14:38
mgoddardso 1, removing admin endpoints14:38
fricklerthe argument not to clean up may be that users can be using them without deployers being aware of it14:38
mgoddarda reason we might not want to do it on upgrade is backwards compat14:38
fricklersince it is a local config in clouds.yaml or whereever14:39
mmalchukwhat if after upgrade some need a revert?14:39
yoctozeptook, makes sense14:39
mnasiadkayoctozepto: it was used in keystone client, but it doesn't default to it anymore (at least now)14:39
yoctozeptommalchuk: not something we can support really14:39
mgoddardOTOH, we didn't make it optional, so they're essentially running custom endpoints14:39
yoctozeptomnasiadka:  awesome14:39
mgoddardand if they change FQDN or VIP, the admin endpoints will be invalid14:40
fricklerusers may to some time to update their clients14:40
yoctozeptomgoddard: optional what? (I did not follow)14:40
mgoddardyoctozepto: optional admin endpoints14:40
fricklers/to/take/14:40
yoctozeptomgoddard: ack14:41
yoctozeptoso they can go desync14:41
yoctozeptowhich is bad14:41
yoctozeptoand surprising probably14:41
mnasiadkaKolla-Ansible created those endpoints, Kolla-Ansible should remove them on upgrade - if something breaks - the user can add the endpoint back manually (and therefore they will be treated as something beyond k-a control)14:41
mnasiadkamakes sense?14:41
yoctozepto+214:42
mmalchukok. indeed make sense14:42
mgoddardalso what if I deploy region214:43
yoctozeptobut let's leave yoga alone? this needs to be advertised better I guess14:43
yoctozeptomgoddard: then you will have region2 deployed14:43
yoctozeptoba-dum-tss14:43
yoctozepto:D14:43
mgoddardwith no admin endpoints14:43
mgoddardanyways14:43
mnasiadkaYes, let's do it in Zed I think - enough time to understand if fresh deployments without admin endpoints break any project14:43
mgoddard+114:44
yoctozeptook, then I will focus on cleaning up admin endpoints14:44
mnasiadkaOk, enough on that I think :)14:44
mnasiadkaSecond additional topic is: (frickler) Monthly stable releases https://review.opendev.org/c/openstack/kolla/+/84428614:45
fricklerwe tackled that already I guess14:45
mnasiadkaI think so14:45
fricklerjust wanted to have the link handy14:45
mnasiadkagoodie14:45
mnasiadka#topic Open discussion14:45
mnasiadkaAnyone, anything?14:46
mmalchukplease take a look https://review.opendev.org/c/openstack/kayobe/+/84003314:46
mmalchukmgoddard know it14:46
mmalchukbad issue need to be backported too14:46
fricklerwhen is the switch from yoga to master due?14:47
* frickler wanting to dump centos :D14:47
mmalchukalso https://review.opendev.org/c/openstack/kolla/+/84247214:47
mmalchukwe need this customized from kayobe14:48
mnasiadkafrickler: I think once we have CentOS Stream 9 working, and now we don't.14:48
yoctozeptomnasiadka: seriously? I thought we had a schedule for these things ;-)14:49
fricklerso we wait without limit for c9s?14:49
yoctozeptoif cs9 is not there, we drop cs8 and live happily without it for the time being14:49
mnasiadka3 months or 3 years, whatever :)14:49
mnasiadkaYeah, just laughing14:49
mmalchukplease +W : https://review.opendev.org/q/I3ab603f7cab7946ea8f2e063fe91190d6592066a14:50
mnasiadkadone14:51
mmalchukthx14:51
mnasiadkaok14:51
mnasiadka#endmeeting14:51
opendevmeetMeeting ended Wed Jun  1 14:51:50 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:51
opendevmeetMinutes:        https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.html14:51
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.txt14:51
opendevmeetLog:            https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.log.html14:51
mnasiadkaThanks for joining!14:51
mnasiadkaDoes anybody want to chair next weeks meeting? I'll be in Berlin and have no clue if I'll be able to run it.14:52
yoctozeptoI'll be out as well14:52
yoctozeptoI think we need to cancel it14:52
yoctozeptobtw, I will be out also for the one in two weeks14:53
yoctozeptoand don't count on me for the first two weeks of June in general ;-)14:53
mnasiadkaOk then, will cancel :)14:53
yoctozeptothanks mnasiadka 14:53
yoctozeptohave a great evening everyone14:53
* yoctozepto off14:53
hrwre15:19
opendevreviewMarcin Juszkiewicz proposed openstack/kolla master: Allow to overwrite repos.yaml file  https://review.opendev.org/c/openstack/kolla/+/84431115:19
hrwoops, missed meeting15:19
hrwI hope someone find it useful15:20
hrw(patch, not missing meeting)15:27
opendevreviewPierre Riteau proposed openstack/kayobe master: Fix potential use of invalid group name  https://review.opendev.org/c/openstack/kayobe/+/84431515:36
hrwuf. reproduced aarch64 bug15:36
hrwnow, how to connect to serial from console...15:42
hrwvirsh++15:45
hrwmeh. Debian cloud image works15:59
hrw  Booting `Debian GNU/Linux'15:59
hrwLoading Linux 5.16.0-0.bpo.4-cloud-arm64 ...15:59
hrwLoading initial ramdisk ...15:59
hrw/dev/vda1: clean, 25291/122880 files, 180813/491515 blocks15:59
hrwGROWROOT: CHANGED: partition=1 start=262144 old: size=3932127 end=4194271 new: size=41680863 end=4194300715:59
opendevreviewMerged openstack/kolla-ansible stable/xena: Control Masakari monitors deploy  https://review.opendev.org/c/openstack/kolla-ansible/+/84410716:06
opendevreviewMerged openstack/kolla-ansible stable/yoga: Control Masakari monitors deploy  https://review.opendev.org/c/openstack/kolla-ansible/+/84410616:08
opendevreviewMerged openstack/kolla-ansible stable/wallaby: Control Masakari monitors deploy  https://review.opendev.org/c/openstack/kolla-ansible/+/84410816:08
guesswhat   Why is here mention https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html#networking about octavia_network_interface which is not used in code for openswitch, which is default mode ? Also why is there then mention about octavia_network_type: "tenant" ? Its the same and there is any mention about configuration for16:56
guesswhatdefault mode -> openvswitch16:56
hrwmnasiadka, frickler, yoctozepto: qemu 5.2/6.2 is fine, 7.0 is not. will bisect it tomorrow17:02
opendevreviewMarcin Juszkiewicz proposed openstack/kolla-ansible master: Switch to Cortex-A72 cpu on AArch64  https://review.opendev.org/c/openstack/kolla-ansible/+/84432117:11
hrwmay solve the problem17:11
hrwhttps://gitlab.com/qemu-project/qemu/-/issues/1054 reported17:38
guesswhatmnasiadka i wrote two days ago: "but you can create a linux bridge, virtual ethernet pair and plug in veth to ovs - just like we do in Kayobe,..." Can You elaborate more, please? Or point me to kayobe code..  Should I create veth pair and bridge, assign vethA to bridge and add vethB port openvswitch. To br-int ? A set address to bridge on host18:13
guesswhatfrom range of octavia management network? Thanks18:13
guesswhat*you18:13
opendevreviewRadosław Piliszek proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs  https://review.opendev.org/c/openstack/kolla-ansible/+/74134018:51
opendevreviewRadosław Piliszek proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs  https://review.opendev.org/c/openstack/kolla-ansible/+/74134018:51
yoctozeptohrw, frickler, mnasiadka: looks like the "other part" of the issue is in the bootloader?19:19
yoctozeptoas ubuntu boots19:19
guesswhatQuestion... Why is octavia_network_type: "tenant" not reliable for production ?  Thanks21:55
hrwyoctozepto: ?22:03

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