opendevreview | James Kirsch proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs https://review.opendev.org/c/openstack/kolla-ansible/+/741340 | 03:20 |
---|---|---|
manohar_joshi | Hello everyone | 08:11 |
opendevreview | Piotr Parczewski proposed openstack/kolla master: WIP: Add Opensearch image(s) https://review.opendev.org/c/openstack/kolla/+/830373 | 08:38 |
kevko | morning \o/ | 08:51 |
guesswhat | Hello, Guys, I need help with Octavia, still can not get it work.. Anyone is willing to help me? Thanks | 10:10 |
hrw | morning | 10:11 |
hrw | libvirt-- | 10:11 |
opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/yoga: Improve MariaDB restore procedure https://review.opendev.org/c/openstack/kolla-ansible/+/844197 | 10:11 |
opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/xena: Improve MariaDB restore procedure https://review.opendev.org/c/openstack/kolla-ansible/+/844198 | 10:11 |
opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/wallaby: Improve MariaDB restore procedure https://review.opendev.org/c/openstack/kolla-ansible/+/844199 | 10:11 |
hrw | I 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 it | 10:11 |
hrw | hm. apparmor... | 10:13 |
hrw | heh. 5.17.0-3 recommends it | 10:14 |
mnasiadka | ok, horizon for python 3.10 is broken, so Ubuntu Jammy is a bit stalled | 10:24 |
mgoddard | mnasiadka: but otherwise working? | 10:29 |
hrw | mnasiadka: yay | 10:33 |
guesswhat | Guys, 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? Thanks | 10:45 |
mnasiadka | mgoddard: otherwise seems ok | 10:54 |
guesswhat | What 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 and | 11:12 |
guesswhat | octavia_network_interface_address should set correct IP if there is more then one IP, right? | 11:12 |
opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Add proxysql support for database https://review.opendev.org/c/openstack/kolla-ansible/+/770215 | 11:16 |
opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Edit services roles to support database sharding https://review.opendev.org/c/openstack/kolla-ansible/+/770216 | 11:16 |
opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [CI] Test ProxySQL with shards in the nova cells scenario https://review.opendev.org/c/openstack/kolla-ansible/+/770621 | 11:17 |
opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Trigger cells job https://review.opendev.org/c/openstack/kolla-ansible/+/838916 | 11:17 |
kevko | guesswhat: IP for octavia has to be from octavia subnet range defined in openstack | 11:17 |
kevko | it is for worker and healthmanager to be able contact amphorae instances | 11:17 |
guesswhat | kevko: yes, but how is routing done for worker and octavia to be able to reach octavia mngmnt network? | 11:18 |
guesswhat | *healthmanager | 11:18 |
kevko | if you have octavia_auto_configure everything is done | 11:21 |
guesswhat | thats not true | 11:21 |
guesswhat | creating loadbalancer fais, coz controller ( worker, healthmanager ) can not reach loadbalancer | 11:22 |
guesswhat | *fails | 11:22 |
guesswhat | thats why i am asking here for 3 days already, docs are misleading... | 11:22 |
kevko | are u using auto_configure ? | 11:23 |
guesswhat | of course, its the default option | 11:24 |
kevko | hmm, i don't ....i just checked code | 11:25 |
guesswhat | https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/group_vars/all.yml#L1202 | 11:25 |
kevko | i have simple virtualized env ...so i have just physnet2:br-ex2 in neutron | 11:25 |
kevko | and then i have port inserted into br-ex2 | 11:26 |
guesswhat | manually? | 11:26 |
kevko | nope | 11:26 |
hrw | An 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 |
hrw | we have too many extra steps to check in docs | 11:26 |
kevko | neutron_bridge_name: "br-ex,br-ex2" neutron_external_interface: "external,octavia" these two i have in globals ... | 11:27 |
kevko | but 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' dir | 11:27 |
hrw | nops | 11:28 |
kevko | hrw: kolla_address is filter inseide kolla-ansible ..could you import it in python ? | 11:28 |
guesswhat | kevko: i have also virtualized env... i tried the same, everything else related to octavia is default? | 11:28 |
guesswhat | and br-ex2/octavia interface is just a network between controllers? | 11:29 |
kevko | guesswhat: 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,neutron | 11:30 |
guesswhat | I would like to see Yours globals.yaml file | 11:31 |
guesswhat | Are You using ubuntu ? | 11:31 |
guesswhat | netplan + globals.yaml will help me to understand where is the difference | 11:31 |
guesswhat | did you touched octavia_amp_network ? | 11:32 |
kevko | guesswhat: https://paste.opendev.org/show/bIZLT1B3e0uplSVRFrq1/ | 11:33 |
kevko | this will help you i think | 11:33 |
kevko | guesswhat: 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 |
guesswhat | kevko: thanks and has that L2 gateway? and do you have disabled gateway in lb-mgmt-net network? | 11:36 |
guesswhat | *L2 network | 11:36 |
kevko | so octavia-healthmanager interface is accessible : octavia-healthmanager <- same-physical-network-outside -> octavia -> br-ex2 -> PORTS of amphoraes | 11:36 |
guesswhat | i 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 |
kevko | guesswhat: i have script for resources create | 11:38 |
kevko | guesswhat: https://paste.opendev.org/show/bVMUbysW5mVR23LOSPzB/ | 11:38 |
hrw | kevko: uninstalled k-a, updated requirements, installed, works ;d | 11:39 |
kevko | hrw: \o/ :) | 11:39 |
guesswhat | kevko, thanks ! so its external, flat network ( where is available dhcp server ) and octavia management network is directly visible via that physnet2 | 11:43 |
guesswhat | *external dhcp, and external L2 without gateway | 11:44 |
guesswhat | correct? | 11:44 |
kevko | guesswhat: 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 |
guesswhat | yes, 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 linuxbrdige | 11:45 |
kevko | guesswhat: 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 |
kevko | so it's directly accessible | 11:46 |
kevko | i 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 | *inseide | 11:48 |
kevko | *inside | 11:48 |
guesswhat | didnt you try to use vlan instead of flat ? | 11:49 |
kevko | didn't | 11:57 |
hrw | ./tools/init-runonce and can check what is wrong | 12:01 |
hrw | 2022-06-01 14:02:46.440 7 ERROR nova.compute.manager [instance: 7313f4d0-a7a0-4bf3-812b-680b5eb666f4] nova.exception.UEFINotSupported: UEFI is not supported | 12:03 |
hrw | meh | 12:04 |
* hrw out | 12:05 | |
opendevreview | Dr. Jens Harbott proposed openstack/kolla master: Add documentation to create monthly stable releases https://review.opendev.org/c/openstack/kolla/+/844286 | 12:22 |
guesswhat | kevko: cz? | 13:17 |
kevko | guesswhat: yeah | 13:28 |
opendevreview | Merged openstack/kolla-ansible master: Do not use keystone_admin_url et al https://review.opendev.org/c/openstack/kolla-ansible/+/843727 | 13:30 |
guesswhat | kevko: PM | 13:46 |
kevko | guesswhat: replied :D | 13:55 |
mnasiadka | #startmeeting kolla | 14:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
opendevmeet | The meeting name has been set to 'kolla' | 14:00 |
frickler | mnasiadka: meeting time? | 14:00 |
frickler | ha, jinx | 14:01 |
frickler | o/ | 14:01 |
yoctozepto | o/ | 14:01 |
mgoddard | \o | 14:01 |
mnasiadka | #topic rollcall | 14:01 |
mnasiadka | now you can repeat ;-) | 14:01 |
mnasiadka | o/ | 14:01 |
mmalchuk | hi | 14:01 |
yoctozepto | let's move on mnasiadka | 14:03 |
mnasiadka | #topic agenda | 14:03 |
mnasiadka | * Announcements | 14:03 |
mnasiadka | * Review action items from the last meeting | 14:03 |
mnasiadka | * CI status | 14:03 |
mnasiadka | * Release tasks | 14:03 |
mnasiadka | * Current cycle planning | 14:03 |
mnasiadka | * Additional agenda (from whiteboard) | 14:03 |
mnasiadka | * Open discussion | 14:03 |
mnasiadka | #topic Announcements | 14:03 |
mnasiadka | OpenInfra Summit next week - but you know that | 14:03 |
mnasiadka | #topic Review action items from the last meeting | 14:04 |
mnasiadka | let's check | 14:04 |
frickler | #link https://grafana.opendev.org/d/c0d59dad13/kolla-failure-rate?orgId=1 | 14:04 |
frickler | still waiting on feedback whether to add more jobs or less. also maybe second page for arm jobs? | 14:04 |
mnasiadka | frickler update grafana dashboard | 14:04 |
mnasiadka | hrw to look for aarch64 failures in yoga/master | 14:04 |
mnasiadka | hrw to look for aarch64 failures in yoga/master | 14:04 |
mnasiadka | frickler add a mention of doing monthly point releases for stable branches in kolla meetings docs page | 14:04 |
mnasiadka | mnasiadka add more release liasons | 14:04 |
frickler | also https://review.opendev.org/c/openstack/kolla/+/844286 with questions for the stable releases | 14:05 |
mnasiadka | frickler: Ceph jobs failure rates? | 14:05 |
frickler | mnasiadka: sure, just tell me what to add | 14:05 |
frickler | ceph came to my mind, too | 14:05 |
yoctozepto | failure rates most of the time at 100% do not sound well and it's not true | 14:06 |
frickler | regarding aarch I did a look too, seems debian has updated qemu which is broken | 14:06 |
yoctozepto | I don't think this gives the right perspective | 14:06 |
frickler | yoctozepto: which ones are you talking about? | 14:07 |
yoctozepto | frickler: kolla-ansible-ubuntu-source | 14:08 |
mnasiadka | well, all of the graphs show 100% failure rate from time to time | 14:08 |
mnasiadka | or are these not percent? | 14:08 |
yoctozepto | I mean, we probably need a different timewindow | 14:08 |
yoctozepto | so as not to get one failed jobs create a spike to 100% | 14:09 |
yoctozepto | it's nice to have the graphs but I struggle with their interpretation | 14:09 |
frickler | iirc 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 so | 14:10 |
mnasiadka | even if you go to 6 months time window - these are still spikes to 100% | 14:11 |
mnasiadka | https://grafana.opendev.org/d/c0d59dad13/kolla-failure-rate?orgId=1&viewPanel=4&from=now-6M&to=now | 14:11 |
frickler | the calculation still looks at 24h intervals | 14:11 |
mnasiadka | right | 14:11 |
frickler | https://opendev.org/openstack/project-config/src/branch/master/grafana/kolla.yaml#L36 | 14:11 |
frickler | movingAverage(...'24hours') | 14:12 |
frickler | I'll try to change that | 14:12 |
mnasiadka | ok, anyway - we need to be able to see some benefit in those dashboards | 14:12 |
mnasiadka | but thanks for working on them | 14:12 |
mnasiadka | #action frickler to continue working on Grafana dashboards | 14:12 |
frickler | maybe once we no longer have large incidents every couple of days, things will look better | 14:13 |
mnasiadka | hrw is absent, what about those master/yoga failures, are those fixed? | 14:13 |
frickler | no, aarch debian is completely broken with their qemu update | 14:13 |
yoctozepto | yeah, whatever happened | 14:13 |
yoctozepto | cirros did not adapt | 14:13 |
yoctozepto | I heard ubuntu worked | 14:13 |
frickler | we can either test with ubuntu cloud image instead of cirros or discuss whether we can use older qemu from not -backports | 14:14 |
frickler | or somebody can tell me what I need to change in cirros | 14:14 |
mnasiadka | ok, so it's still in progress | 14:14 |
frickler | I tested with newer kernel and grub, that didn't help | 14:14 |
mnasiadka | #action hrw to look for aarch64 failures in yoga/master | 14:14 |
mnasiadka | frickler add a mention of doing monthly point releases for stable branches in kolla meetings docs page - I've seen a patch in progress with comments | 14:15 |
frickler | #link https://review.opendev.org/c/openstack/kolla/+/844286 | 14:15 |
frickler | once those questions are answered, I can also create the release patch(es) | 14:16 |
mnasiadka | commented | 14:16 |
mnasiadka | let's go on | 14:16 |
mnasiadka | I haven't requested more releases liaisons | 14:16 |
mnasiadka | #action mnasiadka add more release liasons | 14:16 |
mnasiadka | #topic CI status | 14:17 |
yoctozepto | green after yet another emergency weekend | 14:17 |
mnasiadka | fantastic | 14:17 |
yoctozepto | thankfully, me and frickler seem to be workaholics :-) | 14:17 |
mnasiadka | #topic Release tasks | 14:17 |
mmalchuk | end me) | 14:18 |
mmalchuk | and me) | 14:18 |
mnasiadka | R-18 - nothing on our radar I guess | 14:18 |
mnasiadka | There was somebody on the list complaining about Kolla 14.0.0 failing to build Ubuntu | 14:18 |
mnasiadka | Did we fix that and should release 14.0.1? | 14:18 |
yoctozepto | mmalchuk: :-) | 14:19 |
yoctozepto | mnasiadka: frickler will release | 14:19 |
yoctozepto | I mean | 14:19 |
yoctozepto | propose | 14:19 |
yoctozepto | we fixed that indeed | 14:19 |
mnasiadka | ok | 14:19 |
mnasiadka | frickler: happy to follow the process we agree to and post new point releases for Yoga? | 14:20 |
priteau | I've replied, they confirmed that it is fixed | 14:20 |
frickler | frickler: well I'd propose stable releases for all branches in one go was my idea | 14:20 |
frickler | ehm ... mnasiadka: | 14:21 |
yoctozepto | yoctozepto: that's a good idea | 14:21 |
yoctozepto | yoctozepto: thank you | 14:21 |
yoctozepto | :D | 14:21 |
mnasiadka | yeah, in one go - sorry ;-) | 14:21 |
mnasiadka | #topic Current cycle planning | 14:21 |
mnasiadka | Ubuntu 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 |
yoctozepto | what's wrong with mariadb? | 14:24 |
yoctozepto | (just curious) | 14:24 |
mnasiadka | https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634 | 14:25 |
mnasiadka | fix is out, but in kinetic-proposed | 14:25 |
mnasiadka | (and we're using mariadb packages from Ubuntu repo for now, because upstream MariaDB hasn't built those yet) | 14:25 |
mnasiadka | Anything on other priorities? | 14:27 |
yoctozepto | the solution is "disable lto" nice | 14:27 |
yoctozepto | so much for optimisations | 14:27 |
yoctozepto | :D | 14:27 |
mnasiadka | https://etherpad.opendev.org/p/KollaWhiteBoard - L289 | 14:27 |
yoctozepto | mnasiadka: I guess we should discuss letsencrypt | 14:27 |
yoctozepto | I posted some comments there | 14:27 |
yoctozepto | please check them out | 14:27 |
mnasiadka | yoctozepto: yeah well, tell me why mariadb checks kernel version ;-) | 14:28 |
yoctozepto | (I have as I promised to do it May :D ) | 14:28 |
mnasiadka | ok, I'll try to look into it - mgoddard got some cycles to look there as well? | 14:28 |
mgoddard | yeah, should do | 14:29 |
mnasiadka | so let's try to focus on getting this in finally, then we can look at podman | 14:29 |
mnasiadka | #topic Additional agenda (from whiteboard) | 14:30 |
mnasiadka | (yoctozepto) https://review.opendev.org/c/openstack/kolla/+/843751/ | 14:30 |
yoctozepto | kevko will also want his proxysql in | 14:30 |
yoctozepto | we merged the first part | 14:30 |
yoctozepto | and regarding that patch posted by mnasiadka: | 14:31 |
yoctozepto | how do we go about removing the admin endpoints? | 14:31 |
yoctozepto | we did not in yoga, we are leaving users with admin endpoints | 14:31 |
yoctozepto | for keystone it matters what this points to but we don't have any strategy atm to apply | 14:31 |
yoctozepto | that's what needs discussion | 14:32 |
frickler | I would leave it to deployers to decide when to clean up | 14:32 |
mmalchuk | agree | 14:33 |
frickler | and it doesn't hurt if they decide not to do it at all | 14:33 |
yoctozepto | works for me | 14:33 |
mnasiadka | case solved I guess | 14:34 |
yoctozepto | but there is a discussion with mgoddard that he wants it differently | 14:34 |
yoctozepto | let me find that | 14:34 |
yoctozepto | https://review.opendev.org/c/openstack/kolla-ansible/+/840898 | 14:34 |
mnasiadka | well, we have been removing endpoints in the past (like cinderv2) | 14:34 |
mgoddard | I'd prefer that upgraded systems look like fresh deploys, where possible & sensible | 14:35 |
mgoddard | what's the argument for leaving the admin endpoints? | 14:35 |
yoctozepto | yeah, so maybe do it again and be gone with that extra unused endpoint? | 14:35 |
yoctozepto | mgoddard: I guess the argument is us being lazy - it's still a valid argument! | 14:35 |
yoctozepto | :D | 14:35 |
frickler | that patch is about changing the URL for the keystone admin endpoint, that's a different thing | 14:36 |
yoctozepto | frickler: well, different but very much related | 14:36 |
yoctozepto | update or remove | 14:36 |
yoctozepto | that is the question | 14:36 |
yoctozepto | and I guess then we should remove all admin endpoints | 14:37 |
frickler | for the other service's admin endpoints, the URL is the same as internal iirc. so they will continue to work | 14:37 |
yoctozepto | btw, is the keystone admin endpoint still used anywhere? maybe we should run tempest soon to discover this ;d | 14:37 |
frickler | for the different port, we want to cleanup haproxy so it will no longer work | 14:37 |
mmalchuk | yoctozepto: but we'r lazy) | 14:37 |
tibeer | @frickler is that something for ra-rau or me? | 14:37 |
yoctozepto | frickler: I agree with mgoddard that it's better to clean up | 14:38 |
mgoddard | agree with frickler, they are fairly different things | 14:38 |
mgoddard | so 1, removing admin endpoints | 14:38 |
frickler | the argument not to clean up may be that users can be using them without deployers being aware of it | 14:38 |
mgoddard | a reason we might not want to do it on upgrade is backwards compat | 14:38 |
frickler | since it is a local config in clouds.yaml or whereever | 14:39 |
mmalchuk | what if after upgrade some need a revert? | 14:39 |
yoctozepto | ok, makes sense | 14:39 |
mnasiadka | yoctozepto: it was used in keystone client, but it doesn't default to it anymore (at least now) | 14:39 |
yoctozepto | mmalchuk: not something we can support really | 14:39 |
mgoddard | OTOH, we didn't make it optional, so they're essentially running custom endpoints | 14:39 |
yoctozepto | mnasiadka: awesome | 14:39 |
mgoddard | and if they change FQDN or VIP, the admin endpoints will be invalid | 14:40 |
frickler | users may to some time to update their clients | 14:40 |
yoctozepto | mgoddard: optional what? (I did not follow) | 14:40 |
mgoddard | yoctozepto: optional admin endpoints | 14:40 |
frickler | s/to/take/ | 14:40 |
yoctozepto | mgoddard: ack | 14:41 |
yoctozepto | so they can go desync | 14:41 |
yoctozepto | which is bad | 14:41 |
yoctozepto | and surprising probably | 14:41 |
mnasiadka | Kolla-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 |
mnasiadka | makes sense? | 14:41 |
yoctozepto | +2 | 14:42 |
mmalchuk | ok. indeed make sense | 14:42 |
mgoddard | also what if I deploy region2 | 14:43 |
yoctozepto | but let's leave yoga alone? this needs to be advertised better I guess | 14:43 |
yoctozepto | mgoddard: then you will have region2 deployed | 14:43 |
yoctozepto | ba-dum-tss | 14:43 |
yoctozepto | :D | 14:43 |
mgoddard | with no admin endpoints | 14:43 |
mgoddard | anyways | 14:43 |
mnasiadka | Yes, let's do it in Zed I think - enough time to understand if fresh deployments without admin endpoints break any project | 14:43 |
mgoddard | +1 | 14:44 |
yoctozepto | ok, then I will focus on cleaning up admin endpoints | 14:44 |
mnasiadka | Ok, enough on that I think :) | 14:44 |
mnasiadka | Second additional topic is: (frickler) Monthly stable releases https://review.opendev.org/c/openstack/kolla/+/844286 | 14:45 |
frickler | we tackled that already I guess | 14:45 |
mnasiadka | I think so | 14:45 |
frickler | just wanted to have the link handy | 14:45 |
mnasiadka | goodie | 14:45 |
mnasiadka | #topic Open discussion | 14:45 |
mnasiadka | Anyone, anything? | 14:46 |
mmalchuk | please take a look https://review.opendev.org/c/openstack/kayobe/+/840033 | 14:46 |
mmalchuk | mgoddard know it | 14:46 |
mmalchuk | bad issue need to be backported too | 14:46 |
frickler | when is the switch from yoga to master due? | 14:47 |
* frickler wanting to dump centos :D | 14:47 | |
mmalchuk | also https://review.opendev.org/c/openstack/kolla/+/842472 | 14:47 |
mmalchuk | we need this customized from kayobe | 14:48 |
mnasiadka | frickler: I think once we have CentOS Stream 9 working, and now we don't. | 14:48 |
yoctozepto | mnasiadka: seriously? I thought we had a schedule for these things ;-) | 14:49 |
frickler | so we wait without limit for c9s? | 14:49 |
yoctozepto | if cs9 is not there, we drop cs8 and live happily without it for the time being | 14:49 |
mnasiadka | 3 months or 3 years, whatever :) | 14:49 |
mnasiadka | Yeah, just laughing | 14:49 |
mmalchuk | please +W : https://review.opendev.org/q/I3ab603f7cab7946ea8f2e063fe91190d6592066a | 14:50 |
mnasiadka | done | 14:51 |
mmalchuk | thx | 14:51 |
mnasiadka | ok | 14:51 |
mnasiadka | #endmeeting | 14:51 |
opendevmeet | Meeting ended Wed Jun 1 14:51:50 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:51 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.html | 14:51 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.txt | 14:51 |
opendevmeet | Log: https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-06-01-14.00.log.html | 14:51 |
mnasiadka | Thanks for joining! | 14:51 |
mnasiadka | Does 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 |
yoctozepto | I'll be out as well | 14:52 |
yoctozepto | I think we need to cancel it | 14:52 |
yoctozepto | btw, I will be out also for the one in two weeks | 14:53 |
yoctozepto | and don't count on me for the first two weeks of June in general ;-) | 14:53 |
mnasiadka | Ok then, will cancel :) | 14:53 |
yoctozepto | thanks mnasiadka | 14:53 |
yoctozepto | have a great evening everyone | 14:53 |
* yoctozepto off | 14:53 | |
hrw | re | 15:19 |
opendevreview | Marcin Juszkiewicz proposed openstack/kolla master: Allow to overwrite repos.yaml file https://review.opendev.org/c/openstack/kolla/+/844311 | 15:19 |
hrw | oops, missed meeting | 15:19 |
hrw | I hope someone find it useful | 15:20 |
hrw | (patch, not missing meeting) | 15:27 |
opendevreview | Pierre Riteau proposed openstack/kayobe master: Fix potential use of invalid group name https://review.opendev.org/c/openstack/kayobe/+/844315 | 15:36 |
hrw | uf. reproduced aarch64 bug | 15:36 |
hrw | now, how to connect to serial from console... | 15:42 |
hrw | virsh++ | 15:45 |
hrw | meh. Debian cloud image works | 15:59 |
hrw | Booting `Debian GNU/Linux' | 15:59 |
hrw | Loading Linux 5.16.0-0.bpo.4-cloud-arm64 ... | 15:59 |
hrw | Loading initial ramdisk ... | 15:59 |
hrw | /dev/vda1: clean, 25291/122880 files, 180813/491515 blocks | 15:59 |
hrw | GROWROOT: CHANGED: partition=1 start=262144 old: size=3932127 end=4194271 new: size=41680863 end=41943007 | 15:59 |
opendevreview | Merged openstack/kolla-ansible stable/xena: Control Masakari monitors deploy https://review.opendev.org/c/openstack/kolla-ansible/+/844107 | 16:06 |
opendevreview | Merged openstack/kolla-ansible stable/yoga: Control Masakari monitors deploy https://review.opendev.org/c/openstack/kolla-ansible/+/844106 | 16:08 |
opendevreview | Merged openstack/kolla-ansible stable/wallaby: Control Masakari monitors deploy https://review.opendev.org/c/openstack/kolla-ansible/+/844108 | 16: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 for | 16:56 |
guesswhat | default mode -> openvswitch | 16:56 |
hrw | mnasiadka, frickler, yoctozepto: qemu 5.2/6.2 is fine, 7.0 is not. will bisect it tomorrow | 17:02 |
opendevreview | Marcin Juszkiewicz proposed openstack/kolla-ansible master: Switch to Cortex-A72 cpu on AArch64 https://review.opendev.org/c/openstack/kolla-ansible/+/844321 | 17:11 |
hrw | may solve the problem | 17:11 |
hrw | https://gitlab.com/qemu-project/qemu/-/issues/1054 reported | 17:38 |
guesswhat | mnasiadka 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 host | 18:13 |
guesswhat | from range of octavia management network? Thanks | 18:13 |
guesswhat | *you | 18:13 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs https://review.opendev.org/c/openstack/kolla-ansible/+/741340 | 18:51 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs https://review.opendev.org/c/openstack/kolla-ansible/+/741340 | 18:51 |
yoctozepto | hrw, frickler, mnasiadka: looks like the "other part" of the issue is in the bootloader? | 19:19 |
yoctozepto | as ubuntu boots | 19:19 |
guesswhat | Question... Why is octavia_network_type: "tenant" not reliable for production ? Thanks | 21:55 |
hrw | yoctozepto: ? | 22:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!