15:00:57 #startmeeting kolla 15:00:57 Meeting started Wed Apr 7 15:00:57 2021 UTC and is due to finish in 60 minutes. The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:00 The meeting name has been set to 'kolla' 15:01:07 #topic rollcall 15:01:14 \o/ 15:01:22 _o°o_ 15:01:33 (-o-o-) 15:01:56 (-o-O-o-) 15:04:45 #topic agenda 15:04:55 * Roll-call 15:04:57 * Announcements 15:04:59 * Review action items from the last meeting 15:05:01 * CI status 15:05:03 * Review requests 15:05:05 * Wallaby release planning 15:05:07 ** (kolla-ansible) How should we approach the switch to Quay on the user side? 15:05:09 ** (kolla) Should we permanently remove support for debian/binary in Wallaby? 15:05:11 ** (kolla) Or should we move to Debian 'bullseye'? We can build images but it needs work, tests and K-A support 15:05:13 ** (kolla-ansible) Should we deprecate ``enable_host_ntp``? 15:05:15 ** (kolla-ansible) How/when should we handle chrony container removal? 15:05:17 ** Life after monasca-grafana https://review.opendev.org/c/openstack/kolla/+/784901 15:05:19 #topic announcements 15:05:54 #info Kolla is in feature freeze! 15:06:13 Cores, please do not approve feature patches on master that do not have an FFE 15:06:32 Any others? 15:06:49 RP+2 for FFE as usual? 15:07:10 and RP-1 for anything not-this-cycle? 15:07:41 yes 15:08:10 when it the cut off date for patches? 15:08:16 headphoneJames: week ago? 15:08:28 that have FFE 15:08:35 joking, sorry 15:09:05 I think we normally say 2 weeks after FFE, but really ASAP 15:09:46 #topic Review action items from the last meeting 15:09:58 mgoddard email openstack-discuss about quay.io credentials 15:10:00 mgoddard switch kayobe to c8s 15:10:02 no 15:10:04 yes 15:10:10 #action mgoddard email openstack-discuss about quay.io credentials 15:10:20 #topic CI status 15:11:52 monasca-grafana failing, added to allowed-to-fail images 15:12:12 sorry, forgot to update 15:12:24 Train: CentOS 7 curl unable to talk to docker.com (SSL issue) 15:13:05 fixed should be 15:13:12 ok 15:13:16 if it was expire issue 15:13:22 it was not 15:13:29 centos7 is unable to connect to docker.com 15:13:42 it cannot negotiate tls 15:14:53 bah 15:15:06 train seems a bit borked 15:15:19 master: rabbitmq is failing to upgrade in multinode (e.g. ceph) 15:15:32 what's that one? does it always happen? 15:15:33 hm. 'docker run centos:7; yum -y install curl, curl -L https://docker.com' works 15:16:45 I confirm `curl -L https://download.docker.com/linux/centos/7` works fine from a c7 box 15:17:06 yeah, it is something in CI 15:17:24 or perhaps something got fixed 15:17:32 but the problem was not with cert but tls itself afair 15:17:53 mgoddard: that one is random 15:19:06 let's check train today 15:19:39 Mark Goddard proposed openstack/kolla stable/train: Bump OpenStack versions for Train https://review.opendev.org/c/openstack/kolla/+/785222 15:19:41 ^ 2 birds one stone 15:19:55 I think we haven't done that in a while 15:20:07 ;) 15:20:07 yes, we have not 15:20:14 #topic Review requests 15:20:29 +2 15:20:42 https://review.opendev.org/c/openstack/kolla-ansible/+/670104 15:20:43 hrw: at least wait for CI... 15:21:19 needs a second core to complete FFE 15:21:22 mgoddard: fix is right. CI does not allow to pass broken job 15:21:46 hrw: except for non-voting checks, which we always check, right? 15:22:54 anyone else want to review yoctozepto's patch with me? 15:23:15 I heard mnasiadka wants to 15:23:21 I do not understand ansible enough 15:23:49 yoctozepto: please follow up with mnasiadka 15:23:54 any other reviews? 15:24:09 I am fine 15:24:28 #topic (kolla-ansible) How should we approach the switch to Quay on the user side? 15:24:34 yoctozepto: 15:24:50 yes, how? 15:25:33 does it mean 'container_registry: "quay|docker" # choose one' in globals.yml? 15:25:42 or sth like that? 15:26:11 cause as I user I would love to see it with this level of complication 15:26:42 it could be made that simpple 15:27:06 well, then it's already like that 15:27:15 not quire 15:27:16 quite 15:27:19 well 15:27:24 but close 15:27:26 it can ofcourse be as 'choose this or that block of values' as registry/namespace differ 15:28:07 so 15:28:13 documenting in globals.yml 15:28:44 user needs to edit globals.yml before deployment so it is best place imho 15:28:49 I think we missed a question 15:29:04 should we advertise both dockerhub and quay.io to users? 15:29:13 yes, that was the question 15:29:22 I see 3 options 15:29:39 1. go quay 2. go docker 3. say how to choose? 15:29:39 1. support both dockerhub and quay.io 15:30:12 2. support quay.io, keep dockerhub until Victoria is dead 15:30:21 3. support dockerhub, use quay.io for CI only 15:31:29 2nd sounds good to me if it means that only victoria is on dockerhub. 15:31:31 benefit of 3 being that if we decide quay is not the way, we can quietly drop it 15:32:37 we might want to change the namespace to something like openstack.kolla.ci 15:32:43 or test 15:32:57 well, as long as we don't advertise 15:32:59 it's irrelevant 15:33:11 except... search engines... 15:33:26 well, I would not mind? 15:33:41 but perhaps we are sure of quay and want just offer it 15:34:21 are we sure of quay? 15:35:17 let us do whole cycle with quay. publishing to both quay and dockerhub, CI on quay. 15:35:29 this way at end of Xena we will know 15:35:38 I think that would be sensible 15:35:47 lets get 2-3 months under our belt 15:37:05 yep 15:37:07 agreed? 15:37:18 agreed 15:37:25 so not doing anything more at the moment 15:37:27 agreed? 15:37:41 looks like 15:38:36 +1 15:38:42 ok, moving on 15:38:48 #topic (kolla) Should we permanently remove support for debian/binary in Wallaby? 15:38:59 (kolla) Or should we move to Debian 'bullseye'? We can build images but it needs work, tests and K-A support 15:39:12 I think bullseye is the way to go 15:39:17 need to swallow that change 15:39:29 and k-a needs work 15:39:46 how much work are we looking at? 15:39:48 as mariadb/security_reset.expect does not fit 15:40:33 Well, that’s due to newer mariadb than ever I guess 15:41:01 10.5.9 15:41:13 not good 15:41:48 note that this script was not changed since 2015 15:42:02 so probably no one here touched it 15:42:25 hopefully not rocket science to fix though 15:42:43 might be a case of changing some questions & answers 15:42:54 yep 15:42:57 and keeping separate copy for Debian 15:43:06 ok 15:43:16 as we can handle it easily in kolla 15:43:17 let's see how it goes 15:43:58 hrw: resident debian expert, are you willing to handle it? 15:44:08 perhaps with help from kevko 15:44:14 mgoddard: I do not even know what it is supposed to do 15:44:24 hrw: I mean bullseye in general 15:44:30 in general, yes 15:44:33 ok 15:44:37 kolla part is ~done 15:44:57 all images builds, masakari is disabled for binary but it may change 15:45:17 now we need to deploy and check how things look 15:45:36 ok, keep going and speak up if it starts getting too big 15:45:41 #topic (kolla-ansible) Should we deprecate ``enable_host_ntp``? 15:46:02 should we? 15:46:06 I think we should 15:46:38 it's not the default NTP daemon on any supported OS, is it? 15:46:46 it's not 15:46:54 it's not well supported any longer 15:46:55 not supported on CentOS 8 at all 15:47:08 deprecate 15:47:14 can't we just say 'keep time in sync' in docs? 15:47:14 ok, action on it 15:47:54 #action yoctozepto deprecate enable_host_ntp 15:48:17 #topic (kolla-ansible) How/when should we handle chrony container removal? 15:48:55 during upgrade? 15:49:42 separate play that fires even if disabled 15:50:08 and what if someone upgrades and then decides to disable? 15:50:17 we need a strategy on these cleanups 15:50:33 deploy/upgrade is tricky as it is guarded by the boolean 15:51:50 for monasca we added a separate cleanup command 15:53:06 I don't think the general case is something we can decide here 15:53:10 hmm 15:53:14 there are a few variables 15:53:31 disable entire service? disable one container in an enabled service? 15:53:40 stop supporting a service/container? 15:54:11 I feel like if we remove a service, then the upgrade is the right time to handle it 15:54:28 if someone else disables a service, we need a new command to clean up 15:55:00 we have 5 minutes and one more item 15:55:07 so removal only in xena? 15:55:13 yes 15:55:16 ok 15:55:21 #topic Life after monasca-grafana https://review.opendev.org/c/openstack/kolla/+/784901 15:55:22 then no action for now 15:55:34 dougsz promised to handle this on k-a side 15:55:38 right 15:55:58 any more to discuss? 15:55:59 there is at least a sensible alternative of using the Monasca datasource with vanilla Grafana 15:56:11 nothing else on this 15:56:16 makes sense 15:56:25 #topic Open discussion 15:56:35 4 minutes... 15:56:39 anything else? 15:56:43 Doug Szumski proposed openstack/kolla-ansible master: Support enabling Prometheus Fluentd exporter https://review.opendev.org/c/openstack/kolla-ansible/+/785229 15:59:30 thanks all 15:59:32 #endmeeting