15:01:24 #startmeeting kolla 15:01:25 Meeting started Wed May 5 15:01:24 2021 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:29 The meeting name has been set to 'kolla' 15:01:35 #topic Roll-call 15:01:39 \o/ 15:01:46 who else is here? 15:01:56 o/ 15:02:26 o/ 15:02:37 sorry, was recharging drink 15:02:44 #chair mgoddard 15:02:45 Current chairs: mgoddard yoctozepto 15:02:48 glad you here 15:02:51 please continue 15:02:57 ]o[ 15:04:08 \o 15:04:18 #topic agenda 15:04:20 * Roll-call 15:04:22 * Agenda 15:04:24 * Announcements 15:04:26 * Review action items from the last meeting 15:04:28 * CI status 15:04:30 * Wallaby release planning 15:04:32 * Xena cycle planning 15:04:34 ** Ansible (prepackaged collections) vs ansible-base/core 15:04:36 ** Ansible 2.10 and auto transformation of invalid group names (https://github.com/ansible/ansible/issues/56930) 15:04:38 ** master branch life cycle 15:04:40 * Open discussion 15:04:42 #topic announcements 15:04:57 #info Kayobe RC1 & stable/wallaby branch created 15:05:02 Any others? 15:05:10 none here 15:05:41 #topic Review action items from the last meeting 15:05:57 mgoddard to write up Xena PTG summary for openstack-discuss 15:05:58 mgoddard email openstack-discuss about quay.io credentials 15:06:00 yoctozepto create a bug for alertmanager issue 15:06:02 mgoddard fix one line nfv job 15:06:04 yoctozepto deprecate rally & tempest 15:06:06 1: done 15:06:09 2: no! 15:06:14 3: done 15:06:25 4: done 15:06:28 5: done 15:06:48 #action mgoddard email openstack-discuss about quay.io credentials 15:06:53 unsure why this one is so hard 15:07:12 #topic CI status 15:07:51 https://etherpad.opendev.org/p/KollaWhiteBoard 15:07:59 L40 15:08:04 Debian in master/wallaby is broken - no new instance can be created. have to add to whiteboard 15:09:01 added 15:09:37 I saw that was on the bullseye nodepool image job. Does it work on a buster image 15:10:28 ? 15:10:35 I suspect newer libvirt 15:10:48 which we need anyway for wallaby 15:11:06 but but 15:11:12 yoctozepto: yes? 15:11:12 newer images work fine 15:11:17 it's just the host that fails, no? 15:11:23 due to missing cgroup support 15:11:59 what you mean? 15:12:19 I just deployed whole Debian all-in-one. it fails to boot VM 15:12:45 https://zuul.openstack.org/builds?job_name=kolla-ansible-debian-source&branch=master 15:12:52 yeah, but have not we switched the images already? 15:12:58 and it worked with buster on host? 15:13:05 jobs seem to pass on a buster host 15:13:08 ah. that 15:13:12 at least sometimes 15:13:28 e.g. https://zuul.openstack.org/build/381d9350f36a458680d7a4777df45375 15:14:03 and that's buster 15:14:10 yes 15:14:25 has bullseye dropped cgroups v1? 15:15:03 perhaps needs some tweak in the config then? 15:15:06 https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html 15:15:20 OpenStack Victoria (released in bullseye) requires cgroup v1 for block device QoS. Since bullseye also changes to using cgroupv2 by default (see Section 2.2.4, “Control groups v2”), the sysfs tree in /sys/fs/cgroup will not include cgroup v1 features such as /sys/fs/cgroup/blkio, and as a result cgcreate -g blkio:foo will fail. For OpenStack nodes running nova-compute or cinder-volume, it is 15:15:22 strongly advised to add the parameters systemd.unified_cgroup_hierarchy=false and systemd.legacy_systemd_cgroup_controller=false to the kernel command line in order to override the default and restore the old cgroup hierarchy. 15:15:55 3> 15:16:14 (nova-libvirt)[root@jagular machine]# mount|grep cgro 15:16:15 cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) 15:16:35 oh my 15:16:38 that sad 15:16:44 looks like something to go on 15:16:47 deprecate debian as host? 15:16:59 shall we move on? 15:17:16 move on 15:17:40 move on from debian 15:18:32 RabbitMQ 15:18:46 I think we're good apart from Train, correct? 15:19:14 should be 15:19:30 yes 15:19:41 I suggest we focus on getting wallaby out 15:20:31 when is bintray EOL? 15:20:43 4 days ago? 15:22:09 so kolla stable/train is borked? 15:22:54 to me that seems more urgent than wallaby 15:23:05 oh well 15:23:35 let me check 15:24:34 I can try to pick it up over the next few days if you're out of time 15:24:54 Merged openstack/kayobe stable/victoria: CI: switch to quay.io for container images https://review.opendev.org/c/openstack/kayobe/+/789779 15:24:58 Merged openstack/kayobe stable/wallaby: Ubuntu: install qemu-img on seed-hypervisor https://review.opendev.org/c/openstack/kayobe/+/789799 15:25:18 train has a different situation I guess 15:25:20 by 'let me check' I meant 'let me run build' 15:25:39 whiteboard is not relevant, I progressed further actually 15:25:45 https://bintray.com/rabbitmq/ 404 15:25:51 btw, I updated https://ethercalc.openstack.org/kolla-infra-service-matrix 15:26:02 so 15:26:11 in Train we have erlang not from rmq upstream 15:26:24 and we use rmq upstream only on centoses 15:26:41 so need a different approach than that backport 15:26:47 nice, thanks 15:26:57 Merged openstack/kayobe stable/victoria: Stop using platform-python https://review.opendev.org/c/openstack/kayobe/+/789753 15:27:23 INFO:kolla.common.utils.rabbitmq-3.7.24:https://dl.bintray.com/rabbitmq-erlang/rpm/erlang/22/el/7/repodata/repomd.xml: [Errno 14] HTTPS Error 403 - Forbidde 15:27:36 I think I may get back to it 15:27:38 this week 15:27:43 INFO:kolla.common.utils.rabbitmq:Successfully tagged train/centos-source-rabbitmq:12.1.0 15:28:31 tis a shame we don't have that infra service matrix in docs 15:29:14 I think that's enough for CI issues 15:29:25 #topic Wallaby release planning 15:29:27 yeah, that's what it is for 15:29:38 https://etherpad.opendev.org/p/KollaWhiteBoard 15:29:44 L177 15:30:04 so, debian? 15:30:07 I trimmed some completed stuff 15:30:13 cool 15:30:47 kevko: have time to update mariadb shards docs patch? 15:31:06 I added an item to stop the chrony container on upgrade 15:31:36 Otherwise, seems like UCA & bullseye are the big blockers 15:31:44 I added pointer to cgroup 15:32:08 need to deploy on debian/x86-64 and compare issues 15:32:46 on aarch64 it is now nova complaining at neutron so I suspect rmq 15:34:02 what about this one: https://review.opendev.org/c/openstack/kolla/+/787513 15:34:39 I guess it removes that testing/unstable label 15:34:54 although doesn't change that the release is still unstable :) 15:35:13 I am all for 787513 ;D 15:35:17 initial reaction is, can we rely on the pretty name to be stable? 15:35:22 mgoddard: yes 15:36:03 hrw: how do you know? 15:36:16 or it will switch to 'Debian GNU/Linux (11) bullseye' 15:36:31 in both cases we need to adapt as name we use for check will change 15:36:41 or it will switch to 'Debian GNU/Linux 11 (bullseye)' 15:36:45 etc 15:37:13 oh 15:37:22 right, it still says buster now 15:37:54 argh 15:38:00 mgoddard: we either check for 'lsb_release -r -s' or PRETTY_NAME - both will change on bullseye release 15:38:05 I hadn't even noticed that.. 15:38:15 787513 moves that check to be 1st thing on build 15:38:21 and unifies all distros 15:38:35 but I was meaning more generally - can we rely on these strings to be immutable 15:38:49 yes, they will not change during lifecycle 15:38:56 once released 15:39:00 Merged openstack/kolla-ansible stable/wallaby: Deprecate tempest and rally https://review.opendev.org/c/openstack/kolla-ansible/+/789802 15:39:08 we are not the only ones using them 15:40:01 ok 15:40:54 how about UCA 15:41:00 mnasiadka: any progress in debugging? 15:41:49 Not really, we know that something is wrong with external net - router is not pingable 15:42:07 mnasiadka: can you reproduce it locally? 15:42:25 hrw: didn’t try yet - will do tomorrow 15:42:33 so 15:42:40 we switch to wallaby uca 15:42:42 Why are Rally and Tempest getting deprecated? Rally is still quite useful for doing performance and even functional tests. 15:42:49 installs work 15:42:59 and upgrades brek 15:43:01 imtiazc: we're in a meeting currently 15:43:07 yet it does not happen without a switch 15:43:15 Merged openstack/kayobe stable/wallaby: Add os_release variable, build CentOS stream images https://review.opendev.org/c/openstack/kayobe/+/789800 15:45:07 ok, wait for mnasiadka to debug more 15:45:43 On the kayobe side, I think we have all patches we need at least proposed to master 15:46:02 just need to get them merged and backported 15:46:19 speaking of UCA... I just built 190 UCA/xena images ;D 15:46:32 #topic Xena: Ansible (prepackaged collections) vs ansible-base/core 15:46:50 mnasiadka: I think this was your item? 15:47:34 Yes, question which way we want to go 15:48:36 So, the ansible package is the batteries included package with a set of specific collections 15:48:54 Yes, usually a bit older than latest versions 15:48:57 and ansible-core (was ansible-base) is just the core ansible code without collections 15:49:06 we want it 15:49:13 which? 15:49:25 iirc kolla-toolbox has 363MB of ansible collections 15:49:46 that's a good point - we may not have the same answer for toolbox and k-a 15:49:50 well, in toolbox I made a change to install later version of openvswitch collection 15:50:03 so we might use ansible-core + collections in toolbox 15:50:12 and stick to packaged for the user installation 15:50:12 +` 15:50:16 +1 15:50:53 we have ansible only in kolla-toolbox, right? 15:50:54 I suppose the benefit of ansible-core is that we get more control over which collections are in use? 15:51:29 yes, as mentioned - community.openvswitch collection was older in packaged full blown Ansible, and I had to update to get a bug-less version 15:51:52 and it seems Ansible is updating those only on new major release 15:52:15 mgoddard: core 15:52:19 we move faster 15:52:22 and are lighter 15:52:32 what not to love 15:52:50 so let's agree to first do it in toolbox, and see how it goes 15:53:06 OTOH, it would involve an extra step to install collections 15:53:20 we already do this in kayobe 15:53:41 mnasiadka: ++ 15:53:44 anyway I think we need to move to using those FQCNs (long module names) 15:53:59 yeah, we also need to fix some inventory names 15:54:02 :-) 15:54:13 or ignore them 15:54:15 ...which is the next topic actually 15:54:19 that's I think the second topic in the agenda 15:54:47 I assume we would like to bump up Ansible to 2.10? 15:55:15 2.10 or 3.0? 15:55:24 I lost count which is latest now 15:55:47 3.0 is packaged, that uses 2.10 ansible-core :D 15:56:00 we are on 2.10 max 15:56:26 and 2.9 min 15:56:32 yes 15:56:51 So I guess it would make sense to bump min to 2.10, and think about bumping max to 2.11 15:57:07 but bumping max will bring problems like the next agenda item 15:58:11 ok 15:58:36 it seems it was done only for users unaware that - is not a part of python var name 15:58:37 oh well 15:58:56 #topic Ansible 2.10 and auto transformation of invalid group names (https://github.com/ansible/ansible/issues/56930) 15:59:06 then we tell users what the config should be :-) 15:59:30 I don't think Ansible will stop working with 'invalid' group names? 15:59:47 it seems it would make too many ppl unhappy 16:00:16 so do we need to do it? 16:01:03 We're out of time 16:01:33 Hopefully we'll get to stable branch lifecycle next time 16:01:50 Since we're basically at the point of needing to choose 16:01:52 thank you mgoddard 16:01:56 I think we can delay it, but it will bite us sooner or later :) 16:02:12 I added some notes about the ansible changes to the priority list on the whiteboard 16:02:17 Thanks all 16:02:20 #endmeeting