15:00:40 #startmeeting kolla 15:00:40 Meeting started Wed Jan 19 15:00:40 2022 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:40 The meeting name has been set to 'kolla' 15:00:45 #topic Roll-call 15:00:46 o/ 15:01:03 o/ 15:01:22 \o 15:01:35 \o 15:01:47 /o] 15:01:53 o/ 15:02:08 crowds today, welcome! 15:02:16 #topic Agenda 15:02:17 * Roll-call 15:02:17 * Agenda 15:02:17 * Announcements 15:02:17 * Review action items from the last meeting 15:02:17 * CI status 15:02:19 * Release tasks 15:02:19 * Current cycle planning 15:02:21 * Additional agenda (from whiteboard) 15:02:21 * Open discussion 15:02:24 #topic Announcements 15:02:45 I got my 3rd vaccine last weekend 15:02:53 vaccine shot* 15:03:04 and have no other announcements :-) 15:03:05 yoctozepto: good! 15:03:21 hrw: :-0 15:03:24 :-) * 15:03:33 (typos, typos everywhere :D ) 15:03:35 congrats 15:04:18 mgoddard: yeah, though I feel more like "please accept my condolences" for the time being 15:04:22 welcome to the club etc 15:04:45 anyhow, no announcements - we be moving forward 15:04:53 #topic Review action items from the last meeting 15:04:59 my 2nd and 3rd dose went same way - all fine, arm hurting 2-3 days 15:05:30 mnasiadka to triage security bugs and update them with resolution plan (if needed) 15:05:30 mnasiadka post a patch for docs - standard topics that should be discussed over PTG and then revisited in mid-cycle 15:05:30 kevko to let frickler know whether osism's solution is fine for his use case 15:05:40 hrw: I wish it was arm only :-) 15:05:48 kevko is not around 15:05:52 mnasiadka not around either 15:06:02 and they likely did not do these 15:06:05 restating 15:06:15 #action mnasiadka to triage security bugs and update them with resolution plan (if needed) 15:06:21 #action mnasiadka post a patch for docs - standard topics that should be discussed over PTG and then revisited in mid-cycle 15:06:25 #action kevko to let frickler know whether osism's solution is fine for his use case 15:06:37 #topic Release tasks 15:06:42 oopsie 15:06:44 #undo 15:06:44 Removing item from minutes: #topic Release tasks 15:06:50 #topic CI status 15:07:01 so, regarding CI 15:07:04 we had one fire 15:07:07 in the centos department 15:07:19 a good followup would be to deprecate this department 15:07:32 but I know some like it enough to endure all the pain 15:07:47 ping one? 15:07:53 anyhow, the fire has been extinguished 15:08:12 we can sip our sodas and watch the CI work again 15:08:15 hrw: yeah 15:08:24 so... that would be the status for k and k-a 15:08:31 I've seen k-o-b stuff merging as well 15:08:38 so would assume it's good too 15:08:46 any kayobian to confirm? 15:09:00 Maybe some stable branches of kayobe are still be broken 15:09:17 s/be // 15:09:37 ack 15:10:24 please update the whiteboard when you feel like it 15:10:35 #topic Release tasks 15:11:02 it's R-10 15:11:04 still waiting for R-8: "Switch binary images to current release" 15:11:09 nothing else to report 15:11:26 #topic Current cycle planning 15:11:43 in here we can already tackle the "additional agenda" as it's related today 15:11:50 I tested R-8 situation and images are buildable 15:11:57 (o.horecny2) Podman support 15:12:24 hrw: oh, great! finally some good news :-) 15:12:58 Hi guys, we would like to move forward with Podman things 15:13:00 o_horecny2 halomiva hinermar ^^ 15:13:05 on podman 15:13:13 you wrote: 15:13:18 Asking for code review: 15:13:18 DockerWorker class refactor - https://review.opendev.org/c/openstack/kolla-ansible/+/823783 15:13:18 Systemd container control - https://review.opendev.org/c/openstack/kolla-ansible/+/816724 15:13:18 Next steps? 15:13:19 Deadline? 15:13:19 code freeze for Yoga release 15:13:44 it's good to remind ourselves it's one of major priorities for this cycle 15:13:53 Kolla feature freeze: Mar 21 - Mar 25 15:14:05 yes, we would like to ask you about some code review, because we have already prepared change with podman on top of this changes 15:14:14 and we can have an exception if we *really* need it 15:14:28 but this should be merged by the next ptg in april 15:14:36 I would suggest that we aim for systemd managed docker in yoga 15:14:42 so that we can throw a little podman party 15:15:03 (just setting expectations based on past team review performance) 15:15:17 hmm 15:16:09 bear in mind that podman might bring such questions as 'how to install it', 'how to migrate from docker to podman' 15:16:41 does that seem like a reasonable target? 15:16:46 in case that change with docker managed by systemd is ok for you then we have same thing with podman. 15:17:15 feel free to propose your podman change 15:17:27 but I would suggest that we focus review effort on the systemd patch 15:17:28 yes, I understand. That is what we would like to focus now, but firsly we need to know that way how it is prepared is ok for you 15:17:49 mgoddard: we can have a preview 15:17:56 with no migration path 15:18:21 possibly, although that is an easy way to end up with unfinished features :) 15:18:37 I can action myself to review these patches 15:18:54 halomiva hinermar what do you think? Do you expect some troubles with migration? 15:18:57 same 15:19:13 mgoddard: I think it is possible to end up the other way around - people losing interest because of yet another cycle 15:19:23 one issue may be with having both podman and docker installed 15:19:48 #action yoctozepto to review going-podman patches 15:19:52 #action mgoddard to review going-podman patches 15:19:52 i believe you can't have both docker and podman installed simutaneously 15:20:20 mgoddard, hinermar: last time I checked they can work side by side 15:20:33 but we should not mix the containers this way 15:20:35 I've seen troubles with containers 15:20:40 *containerd 15:21:09 yeah, something could misbehave, though I think they put things in containerd in two different namespaces 15:21:18 or whatever containerd calls that internal isolation 15:21:40 yup 15:21:41 https://github.com/containerd/containerd/blob/main/docs/namespaces.md 15:22:36 the biggest issue I see is with volumes 15:22:40 +1 15:22:49 especially those multi-mounted ones 15:23:04 because for single-mounted ones one can create a simple migration path 15:23:14 but for multi-mounted it's not possible 15:23:24 so we need to down all containers with that mount 15:23:30 migrate volume 15:23:33 and redo them 15:23:36 restart* 15:23:42 which might be trickier than you think 15:23:43 :-) 15:24:08 thankfully we run host networking so no "fun" there 15:25:28 that is right, so we need to test and try to find some trail 15:25:45 I take it we should prevent users from having both managers and create migration tasks, right? 15:26:13 hinermar: we need to figure out a sensible migration path 15:26:18 yes - if we ever have both installed it should only be for migration 15:27:15 but my take on that is that it's important, that's true, but should not prevent us from supporting podman for new installations 15:28:13 yes, that is right 15:28:26 I wouldn't want to paint us into a corner though 15:29:48 anyway, let's see how we get on with systemd 15:30:02 indeed 15:30:23 Do you guys think that this can be done inside upgrade action? Or should be for that prepared something new? 15:30:24 btw, the systemd poc is red 15:30:46 on CI 15:30:48 o_horecny2: I expect it will need a new action 15:30:53 o_horecny2: I would imagine a separate action 15:30:54 mgoddard ++ 15:32:01 yoctozepto: yes, some unite tests need to be finished, but guys firstly wanted to know if it is right way and not spend time on something which can be abandoned 15:33:49 systemd poc was reverted to version without container worker so you can decide if you want to go with abstract class or not 15:34:00 ah, ok 15:34:38 I think abstract class probably makes sense when we introduce podman 15:35:06 mgoddard: yes, it is preparation for podman 15:35:09 but it's not necessary for systemd, and it's hard to see what the interface should be without podman 15:37:20 so do you think that this abstract class patchset is not needed now? And we should focus onlu on systemd patchset? 15:37:32 +1 - focus on systemd 15:37:46 we can return to the container worker afterwards 15:37:52 +1 15:38:17 and what next? implement podman on top of systemd? or thirstly do that refactoring with abstract class? 15:38:27 *firstly 15:39:15 I mean this flow systemd change -> abstract class -> podman ? 15:39:16 I'd just share the podman patch that you have, whichever way it is 15:39:31 that is probably the right order 15:39:45 but we need to see the podman patch to review the abstract class patch 15:40:10 now we have 3 version capable of basic deployment, docker worker + systemd worker, docker worker + container worker + systemd worker, podman worker + docker worker + container worker + systemd worker 15:40:33 with that abstract class or without it? because I believe that when we introduce podman together with abstract class, then you will want to split it again :) 15:40:35 should we push all of them and then we decide what we want to do first? 15:41:11 halomiva: that works for me 15:41:22 if you have a patch that is separate already, then push that 15:42:50 ok, so halomiva and hinermar do you know what to do next? 15:43:12 is it clear for you? 15:43:19 yes 15:44:05 yes 15:45:05 #action halomiva/hinermar propose change for podman 15:45:38 #action halomiva/hinermar propose change for podman 15:45:48 thanks o_horecny2 halomiva hinermar 15:45:57 #topic Open discussion 15:46:04 thanks too 15:46:43 on the secure RBAC front, there is this one: https://review.opendev.org/c/openstack/kolla-ansible/+/815577 15:47:14 adds the service role to service users 15:47:24 I started a discussion on the ML about it 15:47:36 yeah, seen the hi 15:47:50 #link http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html 15:47:51 :D 15:48:03 fat fingered the first one 15:48:06 #link http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html 15:48:32 essentially, keystone gonna break us if we do nothing 15:48:41 so we should do something 15:49:22 unclear right now when they will change the default for enforce_scopes 15:50:30 just putting it out there 15:50:45 we can discuss in the ML, or on the patch 15:51:00 we can save ourselves for the time being by pinning keystone of course 15:51:17 but yeah, we need to address this 15:51:47 I am lacking the time resources to handle it though 15:53:20 I think we are out of other topics today 15:54:59 +1 15:55:08 thank you all for attending 15:55:12 and see you next time 15:55:14 #endmeeting