15:01:35 <yoctozepto> #startmeeting kolla
15:01:35 <opendevmeet> Meeting started Wed Nov 10 15:01:35 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:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <opendevmeet> The meeting name has been set to 'kolla'
15:01:39 <yoctozepto> #topic Roll-call
15:01:44 <yoctozepto> \o/
15:01:49 <adrian-a> \o
15:02:15 <mgoddard> \o
15:02:17 <osmanlicilegi> o/
15:02:28 <priteau> o/
15:03:16 <ohorecny> o/
15:03:25 <hinermar> o/
15:03:38 <yoctozepto> welcome all :-)
15:03:39 <halomiva> o/
15:03:49 <yoctozepto> #topic Agenda
15:04:03 <yoctozepto> * Roll-call
15:04:03 <yoctozepto> * Agenda
15:04:03 <yoctozepto> * Announcements
15:04:03 <yoctozepto> * Review action items from the last meeting
15:04:03 <yoctozepto> * CI status
15:04:05 <yoctozepto> * Release tasks
15:04:05 <yoctozepto> * Yoga cycle planning
15:04:07 <yoctozepto> * Open discussion
15:04:15 <yoctozepto> plus the items from the whiteboard for today
15:04:37 <yoctozepto> which is "Podman"
15:04:51 <yoctozepto> #topic Announcements
15:05:04 <yoctozepto> #info Xena RC2 was released
15:05:32 <yoctozepto> we should be wrapping up Xena as soon as mnasiadka returns from vacations
15:05:48 <yoctozepto> meaning: releasing the final "first version" of Xena
15:05:58 <yoctozepto> any other announcements?
15:06:34 <priteau> There are small fixes in Kayobe that would require an RC3
15:06:44 <priteau> Is kolla/kolla-ansible going to have an RC3 too?
15:06:58 <yoctozepto> priteau: unlikely but it's not an issue
15:07:20 <priteau> Yes, just curious
15:08:35 <yoctozepto> ok, guessing no more announcements
15:08:46 <yoctozepto> #topic Review action items from the last meeting
15:08:51 <yoctozepto> let me see...
15:09:09 <yoctozepto> yoctozepto to run the meeting next week
15:09:14 <yoctozepto> hmm, seems to be happening
15:09:19 <yoctozepto> mnasiadka to triage security bugs and update them with resolution plan (if needed)
15:09:37 <yoctozepto> did not happen so needs to happen later when mnasiadka returns
15:09:41 <yoctozepto> #action mnasiadka to triage security bugs and update them with resolution plan (if needed)
15:09:47 <yoctozepto> yoctozepto hide properly init-runonce
15:09:51 <yoctozepto> did not have time
15:10:00 <yoctozepto> #action yoctozepto hide properly init-runonce
15:10:20 <yoctozepto> #topic CI status
15:10:41 <yoctozepto> the whiteboard says green for all supported branches of all our projects
15:10:49 <yoctozepto> any comments on that?
15:10:53 <priteau> Kayobe is good at the moment
15:10:58 <yoctozepto> :-)
15:11:03 <yoctozepto> thanks
15:11:22 <yoctozepto> I have seen stuff merging to k and k-a as well so betting all well there as well
15:12:05 <yoctozepto> I have clenad up the "issue" under k-a
15:12:08 <yoctozepto> cleaned*
15:12:19 <yoctozepto> as it was no longer valid
15:14:08 <yoctozepto> #topic Release tasks
15:14:18 <yoctozepto> let's see the release cycle plan
15:14:44 <yoctozepto> xena is wrapping up so let's focus on yoga
15:15:10 <yoctozepto> #link https://releases.openstack.org/yoga/schedule.html
15:15:18 <yoctozepto> #link https://docs.openstack.org/kolla/latest/contributor/release-management.html
15:15:32 <yoctozepto> it's R-20
15:15:38 <yoctozepto> no release tasks for this week
15:15:45 <mgoddard> I jumped the gun a bit and proposed patches to bump previous_release
15:15:48 <yoctozepto> though I have seen mgoddard proposing stuff for R-17
15:15:53 <yoctozepto> indeed
15:16:07 <yoctozepto> I don't mind, they are quite safe
15:16:57 <mgoddard> well I think the idea was to try to look like the previous release for a while
15:17:16 <mgoddard> to avoid breakages
15:17:38 <yoctozepto> yeah, but this one part essentially makes us upgrade from xena to xena so it's pretty safe
15:17:54 <yoctozepto> well, we could introduce a bug if we made upgrade=deploy
15:17:58 <yoctozepto> and did not notice
15:18:03 <yoctozepto> but otherwise...
15:18:09 <yoctozepto> anyhow
15:18:11 <yoctozepto> let's continue
15:18:17 <yoctozepto> #topic Yoga cycle planning
15:18:32 <yoctozepto> ok, so it's R-20 in Yoga and we had some glorious plans
15:19:20 <yoctozepto> we can discuss Podman today as it's in the agenda and the relevant folks are around
15:19:27 <yoctozepto> I have already commented on the change
15:19:42 <yoctozepto> #link https://review.opendev.org/c/openstack/kolla-ansible/+/816724
15:19:48 <yoctozepto> so it's about moving to using systemd
15:20:48 <ohorecny> yes, thank you for your comments. Guys from my team need to incorporate them.
15:21:16 <yoctozepto> indeed :-) if you have comments/questions, please feel welcome to put them on the change
15:22:00 <ohorecny> So what do you think, how it looks like. Since this change should we support only docker containers managed by systemd? Or also managed by docker?
15:22:39 <Fl1nt> Hi team!
15:22:44 <yoctozepto> ohorecny: both first; I suggested to go in even smaller steps with refactoring itself being the first so that we can merge 1:1 functionality in new, more flexible, layout
15:22:49 <yoctozepto> hi Fl1nt
15:23:01 <Fl1nt> Sorry for the vanishing, I've been a bit busy lately :(
15:23:13 <Fl1nt> what's up yoctozepto ?
15:24:43 <ohorecny> yoctozepto: So you think that both approaches should be supported? And user can choose ?
15:24:55 <yoctozepto> Fl1nt: we are in the middle of the meeting :-)
15:25:25 <yoctozepto> ohorecny: I think at least code-wise for a moment they should coexist so that we can weed out weird edge cases
15:25:31 <Fl1nt> aaaah forget about that TZ daytime switch fuu, thought I would have make it on time for once :(
15:25:36 <Fl1nt> sorry
15:25:56 <yoctozepto> Fl1nt: no probs
15:27:48 <ohorecny> yoctozepto: aha, ok we went by that way that we are moving it under systemd management
15:28:10 <mgoddard> https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html
15:28:24 <mgoddard> looks like you are using the start/stop approach
15:28:40 <mgoddard> just wondering what are the merits of the --new approach
15:29:55 <yoctozepto> mgoddard: "please review the generated files carefully before using them in production" eh
15:30:14 <yoctozepto> I guess it would be nice to see how they look like
15:30:29 <yoctozepto> but we should nonetheless control the unit files ourselves like we discussed during the ptg
15:31:25 <mgoddard> agreed, I'm just looking at what podman will generate for you
15:31:31 <mgoddard> it gives you two options
15:31:43 <mgoddard> by default it just starts & stops, as in the proposed patch
15:31:47 <ohorecny> yes and this is how it is now for docker and merit is that in case of podman we will do it in similar way
15:31:57 <mgoddard> but if you pass --new, it will create and destroy
15:32:21 <mgoddard> both docker and podman could use either way
15:32:23 <ohorecny> mgodard: genereting by using podman we already had implemented in that older big patchset
15:32:50 <mgoddard> yes, I'm not suggesting we do that
15:33:22 <mgoddard> I'm just saying, podman team has probably thought about this, let's see what they do
15:33:26 <mgoddard> and they offer two options
15:33:31 <mgoddard> so which should we follow?
15:34:15 <yoctozepto> is the destruction on stop?
15:34:25 <mgoddard> yes
15:34:43 <mgoddard> https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html#generate-systemd-unit-file-for-a-container-with-new-flag
15:34:48 <yoctozepto> hmm, sounds like a way to ensure that containers are themselves stateless
15:35:19 <mgoddard> IIRC ceph-ansible does it that way
15:35:43 <Fl1nt> yes and it works perfectly tbn
15:36:58 <ohorecny> yes, that is good point, but it is in future now, when we introduce podman. As we discussed in PTG now we need to support docker with systemd
15:37:15 <yoctozepto> that's correct
15:37:32 <yoctozepto> and I've given you hints how to do it best code-structure-wise
15:37:42 <Fl1nt> ohorecny, you mean lifecycle of containers from systemd units or replace dumb-init with systemd ?
15:38:23 <mgoddard> it's not necessarily in the future - you can use both patterns with docker and podman
15:38:24 <ohorecny> Fl1nt: first option
15:38:24 <yoctozepto> Fl1nt: the first
15:38:38 <Fl1nt> ok thanks :D
15:38:55 <mgoddard> perhaps the proposed approach is most similar to what we have today
15:39:04 <yoctozepto> mgoddard: let's maybe make it optional as well?
15:39:20 <yoctozepto> I want clean code change with the exact same behaviour except for systemd indirection
15:39:42 <Fl1nt> just a quick thought about that, as Ansible community.docker collection is able to really well manage containers lifecycle and that podman control containers from systemd units, is that really useful to integrate for docker?
15:40:10 <mgoddard> Fl1nt: yes
15:40:21 <mgoddard> exact same ansible code for both
15:40:51 <Fl1nt> ok
15:40:58 <yoctozepto> and we need to have more control/interaction with containers than just with the barebones
15:41:13 <Fl1nt> ansible module let you control everything
15:41:24 <Fl1nt> from volume to network and vars/etc
15:41:30 <ohorecny> exactly like mgoddard said, it is not necessary, but in other case we will have much bigger change and "duplicated" code
15:41:37 <yoctozepto> Fl1nt: yeah, but at the cost of repeating a ton of stuff that we have customised for ourselves
15:41:42 <Fl1nt> yep unicity is best.
15:42:11 <Fl1nt> gotcha ^^
15:42:15 <mgoddard> ohorecny: one thing that would help: split the change into two parts. 1. refactor module to module_utils 2. make changes
15:42:25 <Fl1nt> cool initiative about podman indeed :D
15:42:46 <mgoddard> IMO refactors should not change behaviour
15:43:06 <ohorecny> Fl1nt: in that other way the patchset will look like this: https://review.opendev.org/c/openstack/kolla-ansible/+/799229
15:43:28 <ohorecny> it was our first approach, but too big :(
15:44:20 <Fl1nt> yep, I kept an eye on it while being away of IRC ;-)
15:44:45 <ohorecny> mgoddard: ok
15:45:15 <ohorecny> Guys hinermar and halomiva do you agree?
15:45:35 <hinermar> Yes
15:45:38 <ohorecny> they are mostly working on these changes
15:46:10 <ohorecny> ok, so next step is do some refactoring
15:46:49 <yoctozepto> basically what I've commented about :-)
15:46:53 <ohorecny> in case of any questions about review comments please ask directly in change
15:47:03 <yoctozepto> ok, any other Yoga things to discuss at this stage?
15:47:12 <ohorecny> yoctozepto: right, thanks again
15:48:57 <Fl1nt> yoga?
15:49:08 <Fl1nt> Oh release name ^^
15:49:13 <Fl1nt> sorry
15:49:39 <yoctozepto> ohorecny: you are welcome :-)
15:49:42 <frickler> is there anything to discuss regarding "drop admin endpoints"? seems most people agreed to do it
15:50:39 <frickler> so I'd just add a reno and it should be fine?
15:50:56 <frickler> https://review.opendev.org/c/openstack/kolla-ansible/+/816164 for reference
15:51:27 <mgoddard> let's do it
15:52:04 <yoctozepto> TM
15:52:29 <yoctozepto> and I agree wholeheartedly
15:52:52 <yoctozepto> though we could somehow help operators clean up
15:53:10 <yoctozepto> but it's easy to do via a simple script I gues
15:53:13 <yoctozepto> guess*
15:53:20 <frickler> yeah, I was just thinking whether to add a script for cleanup that could be ran on demand
15:53:21 <Fl1nt> aaaah finally that blessed day where admin endpoints disapear !!
15:54:13 <frickler> I'll try to come up with something
15:54:29 <mgoddard> +1 for cleaning up
15:55:06 <mgoddard> I suppose it might cause issues if we do it during the upgrade
15:55:56 <Fl1nt> yeah, should probably be a post-task
15:55:57 <frickler> I wouldn't want to do it automatically, yes. but make it easy for operators as a separate step seems a good compromise
15:56:04 <yoctozepto> well, best to keep it as a helper script
15:56:18 <yoctozepto> ok, we are nearing the end of time
15:56:22 <yoctozepto> #topic Open discussion
15:56:27 <yoctozepto> anything really
15:56:56 <adrian-a> I think this can be closed as Won't Fix, based on last meeting discussion https://bugs.launchpad.net/kolla-ansible/+bug/1554049
15:57:06 <headphoneJames> in Yoga - trying to move towards being able enabling the new system scope policies.
15:57:28 <yoctozepto> adrian-a: agreed from my side
15:57:31 <Fl1nt> so I've a discussion topic
15:57:43 <Fl1nt> since a bit of time now
15:57:45 <Fl1nt> at work
15:58:00 <yoctozepto> headphoneJames: and how's that going?
15:58:09 <headphoneJames> first pass
15:58:10 <headphoneJames> https://review.opendev.org/c/openstack/kolla-ansible/+/815577
15:58:53 <headphoneJames> its ready for comments
15:59:12 <Fl1nt> we're experimenting with an ansible method that gave us the ability in 1 repo to get both similar mechanisms than kolla/kolla-ansible
15:59:21 <Fl1nt> would you be interested in?
15:59:50 <headphoneJames> yoctozepto: The transaction only converts the config for the [keystone_authtoken] section, and not all the configurations for authenticating with other services through keystone.
16:00:37 <mgoddard> Fl1nt: would be interested to take a look
16:01:11 <yoctozepto> headphoneJames: ack, sensible tradeoff
16:01:15 <yoctozepto> ok, out of time
16:01:21 <yoctozepto> thank you all for participating
16:01:27 <yoctozepto> #endmeeting