15:00:15 #startmeeting kolla 15:00:15 Meeting started Wed Oct 2 15:00:15 2019 UTC and is due to finish in 60 minutes. The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:18 The meeting name has been set to 'kolla' 15:00:21 #topic rollcall 15:00:39 (╯°□°)╯︵ ┻━┻ 15:00:44 o\ 15:00:46 o/ 15:00:50 o\ 15:00:57 o/ 15:02:01 Mark Goddard proposed openstack/kolla stable/stein: swift-proxy-server: use Python 3 for Debian/Ubuntu https://review.opendev.org/686178 15:02:53 #topic agenda 15:03:05 * Roll-call 15:03:08 * Announcements 15:03:10 ** Kolla feature freeze this week 15:03:12 ** OpenStack Train RC1s available 15:03:14 * Review action items from last meeting 15:03:16 * CI status 15:03:18 * Train release planning 15:03:20 * Review priorities 15:03:22 * Debian CI changes 15:03:24 ** kolla-ansible Debian/source - https://review.opendev.org/686133 https://review.opendev.org/686134 15:03:26 ** publishing images https://review.opendev.org/686143 15:03:28 * Short-term and long-term proposal for managing non-OpenStack projects Docker images (e.g. sensu case) 15:03:30 * Adding priorities to images at build time (I want 'openstack-base' to be built asap) 15:03:32 #topic announcements 15:03:56 o/ 15:04:14 #info Kolla feature freeze this week 15:04:27 #info OpenStack Train RC1s available 15:04:37 Any others? 15:05:39 #topic Review action items from last meeting 15:05:47 egonzalez to ask about glance-store config for tacker on openstack-discuss 15:06:04 I didn't see such an email 15:06:08 anyone else want to pick it up? 15:06:36 pick up writing mail? 15:06:41 yes 15:06:54 geez, is that so hard :D 15:07:05 pin it at me then 15:07:09 o/ 15:07:15 well, and following up on the response 15:07:32 updating that tacker review to match 15:07:56 #action yoctozepto to ask about glance-store config for tacker on openstack-discuss 15:08:01 start with the mL 15:08:14 #topic CI status 15:08:43 #link https://etherpad.openstack.org/p/KollaWhiteBoard 15:09:24 how we looking? 15:09:31 only pike is broken for kolla now, right? 15:10:55 Michal Nasiadka proposed openstack/kayobe master: Fix customised inventory section https://review.opendev.org/686141 15:11:07 and pike is just +2 away iirc 15:11:10 NFV scenario still broken due to tacker issues 15:11:42 just gave +W for pike/fluentd 15:11:57 k 15:12:32 Kayobe was broken, now fixed 15:12:36 mostly fine 15:12:45 kolla-cli - ??? 15:12:55 no idea, low activity 15:13:25 Pierre Riteau proposed openstack/kayobe master: Fix customised inventory section https://review.opendev.org/686141 15:13:26 looks green on master at least 15:14:00 #topic Train release planning 15:14:25 As mentioned, we're planning to enter feature freeze by the end of this week 15:14:44 I expect there will be some exceptions requested 15:15:16 what will our policy be? 15:15:47 features wanting to merge to master after EOD on Friday need to request an FFE? 15:15:48 strict, but fair :) 15:16:05 mgoddard: +1 for it 15:16:22 I would say normal policy :) +1 15:16:23 I expect I'll need one for cells 15:16:39 mgoddard: and RP-1 for anything which is not train priority? 15:16:56 +1 15:16:59 hrw: yeah 15:17:06 FFE? 15:17:06 (exception for ipv6 pretty please) 15:17:15 feature freeze exception 15:18:40 we have had some less active cores who don't attend meetings start adding +2 after feature freeze previously 15:19:06 punish them ;-) 15:19:09 how can we avoid this? 15:19:19 email to openstack-discuss? 15:19:24 personal email? 15:19:29 personal I think 15:19:32 k 15:19:45 #action mgoddard to email cores about feature freeze 15:20:02 I'll include openstack-discuss too 15:20:08 BCC cores 15:20:30 ok 15:20:35 makes sense 15:20:48 we probably need to find a hard freeze date 15:20:53 make it sound nice :-) 15:21:00 end of oct? 15:21:03 yoctozepto: of course :) 15:21:35 yoctozepto: that's quite a long time after FF 15:21:46 mgoddard: typical 'two weeks' then? 15:21:47 :V 15:21:56 hrw: that sounds about right 15:22:15 * yoctozepto remembers 'two weeks' taking 3 months 15:22:15 we can revisit next week if necessary 15:22:25 this week is 'add whatever you have', then two weeks for 'ops, bug fixes go' and then release 15:22:26 yeah, not planning on that again 15:22:53 well remember we are still dependent on RDO 15:23:03 and whatever surprises they throw at us :) 15:23:14 mgoddard: what about: next meeting we review what we have in FFE/queue, next week we mark what is not going, then end 15:23:21 anyone know status of RDO train repos? 15:23:32 just started centos/binary arm64 build 15:23:33 hrw: seems fair 15:24:47 For anyone interested, we now have some docs on our release process: https://docs.openstack.org/kolla/latest/contributor/release-management.html 15:25:10 I read that once but will re-read 15:25:18 mgoddard: they are working on rc1, https://review.opendev.org/#/q/topic:train_release 15:25:18 I want to finish ipv6 15:25:27 and then help with kolla docs on the support matrix 15:25:30 (kolla-ansible) 15:25:41 then could help rdo 15:25:43 nice 15:25:53 mgoddard: and this: https://review.rdoproject.org/r/#/q/topic:train-jobs 15:26:17 #link https://review.rdoproject.org/r/#/q/topic:train-jobs 15:26:24 #link https://review.opendev.org/#/q/topic:train_release 15:26:48 Merged openstack/kayobe master: Fix container image build with multiple regexes https://review.opendev.org/681504 15:26:49 36 threds on 46 cores with /var/lib/docker in tmpfs == builds which fly 15:27:11 ok, let's move on, we have a few topics this time 15:27:23 #topic Review priorities 15:28:49 I'm still pushing on the cells patches, but will add RP+1 once they're ready 15:29:12 internal TLS has another patch ready https://review.opendev.org/664517 15:29:21 they're the main priorities IIUC 15:29:46 Kayobe has a couple of priority reviews which need looking at 15:29:55 #link https://tiny.cc/kayobe-review-dashboard2 15:30:04 Pierre Riteau proposed openstack/kayobe stable/stein: Fix container image build with multiple regexes https://review.opendev.org/686187 15:30:36 Pierre Riteau proposed openstack/kayobe stable/rocky: Fix container image build with multiple regexes https://review.opendev.org/686188 15:30:55 As we near the end of the release, please start using RP+1 for bug fixes 15:31:17 ok 15:31:30 (following normal rules - ready for review) 15:31:52 I also wondered how many bug fixes we have sitting unreviewed 15:32:04 might try searching for Closes-Bug in gerrit 15:32:11 #topic Debian CI changes 15:32:20 my stuff 15:32:22 kolla-ansible Debian/source - https://review.opendev.org/686133 https://review.opendev.org/686134 15:32:25 publishing images https://review.opendev.org/686143 15:32:29 hrw: take it away 15:32:33 ok. 15:32:49 so we need kolla-ansible tests for Debian images. Source one for start 15:33:16 https://review.opendev.org/686133 should do the job (including build of images) but fails somewhere still 15:33:55 help would be nice as I was not involved in k-a CI before 15:34:21 opinions? questions? 15:35:24 https://review.opendev.org/686143 is to build and publish debian/source images on normal schedule. And on release to make also debian/binary ones as at that time we should have Debian binary packages available 15:35:29 hrw: thanks for starting it 15:35:47 mgoddard: simplifies my life ;D 15:36:16 ones 686143 gets in and we publish images then 686133 may get simplified to remove build of images 15:36:27 s/ones/once 15:36:32 right 15:36:32 opinions? questions? 15:37:10 it makes sense to add a deploy job for debian, given we have put work into getting images building 15:37:39 additional CI load is a bit concerning, but not sure what we can do about that 15:37:54 a single node job isn't too much 15:38:08 well, OSA even runs Ceph jobs on single node :) 15:38:15 I'd definitely suggest trying a local deploy, as you commented in the review 15:38:20 (but that's rather odd, than giving any results) 15:38:30 mgoddard: just finished. worked fine. arm64 3 nodes, no ceph 15:38:40 ARM64 :) 15:38:41 mnasiadka: multinode must be tested ;-) 15:38:55 mgoddard: for me it is easier to have arm64 boxes than x86 ones 15:39:06 hrw: x86 may be different, but hopefully it's a good sign 15:39:08 I probably can do 30+ nodes multinode 15:39:11 yoctozepto: yeah, but we should maybe have one set of multimode jobs with Ceph included 15:39:23 hrw: did you try running init-runonce, and booting a VM etc? 15:39:34 mgoddard: it is end of deploy 15:39:46 http://paste.debian.net/1103748/ is my test script 15:40:04 ok cool 15:40:18 can help with CI debugging if necessary 15:40:29 good opportunity to become more familiar though :) 15:40:31 would be great 15:40:45 anyone else have thoughts? 15:41:42 #topic Short-term and long-term proposal for managing non-OpenStack projects Docker images (e.g. sensu case) 15:41:51 btw thanks hrw 15:41:57 yw 15:42:01 mnasiadka: I think this is you 15:42:11 Yeah 15:42:25 We have long history of images - mainly monitoring related 15:42:31 that we tend to revive when builds break 15:42:44 but we don't really check if they are usable in k-a 15:43:13 sensu, prometheus, tick stack, whatever else there is 15:43:21 Do we want to continue that way? 15:43:33 no 15:43:53 we want to deprecate everything 15:43:55 <3 15:43:58 Yay! 15:44:03 but what kind of procedure for it? 15:44:03 lol 15:44:06 xD 15:44:21 build jobs in rings 15:44:31 I think 2-3 is fine 15:44:56 no sense to break core builds if just sensu broke 15:45:00 it's not limited to monitoring - plenty of less commonly used openstack services are untested 15:45:15 Can they be moved out of tree if we introduce user definable roles? 15:45:30 Yeah, that's one of the options 15:45:35 jovial[m]: we'd need to do the same for kolla images 15:46:06 or we move them out of CI 15:46:15 I would rather propose to deprecate them in U cycle (images and roles) and introduce user definable roles 15:46:32 then a user can use his own sensu/prometheus roles deploying some upstream sensu/prometheus images 15:46:58 and the burden of maintaining this is not on this limited team 15:47:22 who would maintain it? 15:47:31 community 15:47:37 yoctozepto: who? 15:47:44 others 15:47:46 not us 15:47:47 it needs an owner 15:48:20 well, user definable roles needs an owner in Kolla 15:48:45 if we introduce some framework, with which you can use your own home-baked role and images 15:49:10 (probably following our role structure and variables) 15:49:16 this, that... can we start simple? drop whatever extras from CI will make life easier 15:49:24 whatever is not in CI == community 15:49:35 and we stop building those? 15:49:37 but keep them in tree? 15:50:00 not stop 15:50:04 but from another job 15:50:05 iirc periodic build push what it built 15:50:07 only periodic 15:50:08 what if we look at it from the perspective of the support matrix? 15:50:19 indeed mgoddard 15:50:27 we have started to define what is supported, and what is community maintained 15:50:32 include my comment regarding categorization 15:50:44 and we can get there pretty quickly 15:50:45 supported and tested is currently based on kolla ansible CI 15:50:48 regarding what goes where 15:51:01 but we could extend to what we gate on in kolla 15:51:10 I'm rephrasing yoctozepto here I realise 15:51:24 no problem 15:51:58 I know it's annoying having a load of untested code, but we do see people using things we don't realise 15:52:18 and it's one of the great parts of the kolla project - it has a huge range of support 15:52:38 we've started to set expectations via the matrix 15:53:09 it would be a shame to just discard everything that is not tested 15:53:23 well, it's fine that it is that way - but in the end we just fix things we think nobody uses :) 15:53:39 and we just fix them to make the train go to next station 15:54:09 but maybe I'm just complaining :) 15:54:16 yes :p 15:54:29 the thankless job of open source maintenance 15:54:34 haha 15:55:07 discard is a no-no 15:55:12 we have a few ideas being tossed around here 15:55:27 1. deprecate and eventually remove some images/roles 15:55:36 2. extensible framework for images/roles 15:55:46 that "deprecate everything" was a joke though ;p 15:55:52 despite my negativity, I'm +1 for both 15:56:01 yoctozepto: first we need to deprecate mariadb :) 15:56:06 exactly 15:56:09 no 15:56:15 guys 15:56:20 we need to remove "base" - no one is using it 15:56:21 long-term / short-term 15:56:31 let's focus on short-term for a moment 15:56:33 on 1, let's not make sweeping deprecations, but analyse which images we can drop 15:56:43 I think we need to separate "other" images from "core" 15:56:45 using our matrix as a guide 15:56:46 shortterm? limit CI list 15:56:50 oh yes 15:56:56 so that we can keep periodic churning 15:57:02 whatever is not on CI == community. 15:57:06 especially now 15:57:10 3. define categories of gating + non-gating images 15:57:11 and periodic building everything 15:57:12 when we build and publish at once 15:57:19 and lose everything due to sensu 15:57:25 sensu-client in fact 15:57:30 being unable to build 15:57:30 lol 15:57:36 mgoddard: yeah, 3. is probably best to achieve in short-term 15:57:46 define and act upon 15:58:42 these are all things we could look at during Ussuri 15:58:56 I think we have enough to be getting on with for Train 15:59:34 unfortunately yes 15:59:43 fortunately everything is fixed :) 15:59:43 I am afraid :-( 15:59:45 do we need to start tracking potential work for U somewhere? 15:59:58 yup, I think so 16:00:02 mgoddard: let's open a ptg planning ether pad? 16:00:05 high time 16:00:21 wow, positive response 16:00:55 we have features that have been postponed, some pain points identified - there is enough material to gather for ptg :) 16:01:48 anyone going to ptg? 16:02:53 #link https://etherpad.openstack.org/p/kolla-ussuri-ptg 16:02:57 Shanghai? me not 16:03:09 I'll populate it 16:03:18 Maybe let's organise PTG in Poland :) 16:03:28 btw - do we support cinder on nfs? 16:04:20 yeah, PTG in Poland :D 16:04:50 hrw: there is that option in globals.yml... 16:04:56 mnasiadka: D: 16:05:04 yoctozepto: that's not stupid idea 16:05:13 yoctozepto: can you arrange a room at uni? 16:06:35 ok, we're over time 16:06:44 hrw: mind if we push your last topic to next week? 16:06:56 mgoddard: no problem 16:07:01 k 16:07:06 hrw: yeah, that's doable - we could organize a little event for students too 16:07:09 thanks everyone 16:07:14 #endmeeting