15:01:34 <mgoddard> #startmeeting kolla
15:01:35 <openstack> Meeting started Wed Aug  7 15:01:34 2019 UTC and is due to finish in 60 minutes.  The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:39 <openstack> The meeting name has been set to 'kolla'
15:01:45 <openstackgerrit> Marcin Juszkiewicz proposed openstack/kolla-ansible master: Configure docker without guessing how it starts  https://review.opendev.org/672700
15:01:58 <mgoddard> #topic rollcall
15:02:01 <mgoddard> \o
15:02:03 <mnasiadka> o/
15:02:04 <chason> o/
15:02:04 <hrw> o/
15:02:25 <Wasaac> o/
15:02:33 <jovial[m]> 0/
15:02:37 <nafiux> o/
15:02:41 <yoctozepto> o/
15:02:46 <rafaelweingartne> sorry, it is my first meeting. What is a rollcall?!
15:02:56 <Wasaac> It's where everyone waves
15:03:04 <kplant> o/
15:03:07 <yoctozepto> exactly!
15:03:08 <mgoddard> rafaelweingartne: thanks for joining. Raise your hand: o/
15:03:17 <rafaelweingartne> o/
15:03:21 <yoctozepto> like in a classroom
15:03:28 <nafiux> This is my first meeting as well :)
15:03:32 <mgoddard> it just records who is present
15:03:44 <mgoddard> nice turnout today
15:03:48 <mgoddard> #topic agenda
15:03:58 <yoctozepto> mgoddard: everyone waiting for you probably
15:04:20 <mgoddard> * Roll-call
15:04:22 <mgoddard> * Announcements
15:04:24 <mgoddard> ** 99cloud working on kolla-cli - it lives on
15:04:26 <mgoddard> ** PTL (mgoddard) is back
15:04:28 <mgoddard> ** Added review priority for kayobe in gerrit
15:04:30 <mgoddard> ** Kayobe now covered in kolla meetings
15:04:32 <mgoddard> * Review action items from last meeting
15:04:34 <mgoddard> * Kolla whiteboard https://etherpad.openstack.org/p/KollaWhiteBoard
15:04:36 <mgoddard> * Kayobe Stein release status
15:04:38 <mgoddard> * Train release planning
15:04:40 <mgoddard> * Ocata EOL
15:04:42 <mgoddard> * Shanghai summit
15:04:44 <mgoddard> * Ceph ansible migration
15:04:46 <mgoddard> #topic announcements
15:04:48 <mgoddard> #info 99cloud working on kolla-cli - it lives on
15:04:57 <yoctozepto> hurray
15:05:11 <mgoddard> Jeffrey4l_ is the only one I'm aware of who uses IRC
15:05:20 <mgoddard> thanks for picking it up
15:05:46 <mgoddard> I added a deliverable file to the releases repo for the Train cycle, so hopefully it will get its first release then
15:05:57 <mgoddard> #info PTL (mgoddard) is back
15:06:18 <yoctozepto> welcome back
15:06:22 <yoctozepto> everyone missed you
15:06:32 <goldyfruit_> <3
15:06:34 <mgoddard> Family all doing well, trying to get used to working on less sleep
15:06:40 <mgoddard> aw thanks :)
15:06:48 <mgoddard> #info Added review priority for kayobe in gerrit
15:07:02 <hrw> mgoddard: sleep when baby sleeps
15:07:40 <mgoddard> This puts kayobe in sync with other kolla projects - you can now set the review priority field in gerrit to highlight 'important' reviews
15:07:52 <mgoddard> +1 for important, +2 for critical
15:07:58 <hrw> mgoddard: and no longer x/kayobe but kolla/kayobe?
15:08:05 <yoctozepto> openstack/
15:08:15 <mgoddard> hrw: not yet, still waiting on gerrit restart :(
15:08:16 <hrw> or. just no x/
15:08:22 <yoctozepto> :-(
15:08:26 <mgoddard> all patches in review and ready to go
15:08:36 <mgoddard> maybe I should nudge them
15:08:51 <mgoddard> #action mgoddard to ask infra about restarting gerrit
15:08:59 <mgoddard> #info Kayobe now covered in kolla meetings
15:08:59 <yoctozepto> mgoddard: delivery of kayobe for train?
15:09:22 <mgoddard> yoctozepto: yes - patch is approved, but wanted to wait for the rename
15:10:10 <mgoddard> We didn't do a proper introduction as I was away, but please welcome the kayobe team to our meeting
15:10:39 <mgoddard> currently we have jovial[m] in attendance from the core team, and Wasaac is also a contributor
15:10:42 <jovial[m]> hi - I've moved over from kayobe land
15:10:57 <hrw> welcome!
15:10:58 <yoctozepto> welcome jovial[m]
15:11:04 <mgoddard> dougsz has a clash with monasca meeting and priteau is with a customer but should join next time
15:11:08 <yoctozepto> mgoddard; I meant first official release :-)
15:11:09 <mgoddard> (both cores)
15:11:16 <mgoddard> yoctozepto: yeah
15:11:35 <yoctozepto> great!
15:11:45 <yoctozepto> is there a merger of cores?
15:11:53 <mgoddard> all have contributed to kolla too, so I'm sure you recognise each other
15:13:11 <yoctozepto> yeah, sure - wondered if we end up in one team or still two separate?
15:13:14 <mgoddard> I don't want to do an automatic merge of teams - let's keep it based on performance. Anyone who contributes & provides useful reviews on a regular basis can be considered core for that team
15:13:50 <mgoddard> we have several groups in gerrit - kolla-core, kolla-ansible-core, kolla-cli-core, kayobe-core
15:13:54 <hrw> mgoddard: fully agree
15:14:18 <yoctozepto> mgoddard: +1
15:14:34 <mgoddard> great
15:14:39 <mgoddard> lots of announcements today :)
15:14:51 <hrw> yoctozepto: you got all kolla at once as it was normal way but not everyone went that way
15:15:09 <mgoddard> if anyone has more questions about the new setup, please raise in open discussion
15:15:09 * yoctozepto feeling special ;D
15:15:34 <mgoddard> #topic Review action items from last meeting
15:16:03 <mgoddard> no action items
15:16:14 <mgoddard> #topic Kolla whiteboard https://etherpad.openstack.org/p/KollaWhiteBoard
15:16:41 <mgoddard> I merged the kayobe whiteboard into ours
15:17:29 <mgoddard> I think the main CI issues recently are around Ceph, and we have fixes in place or in review
15:17:33 <mgoddard> right yoctozepto?
15:17:38 <yoctozepto> right mgoddard
15:17:44 <yoctozepto> rocky waiting for reviews
15:17:48 <yoctozepto> never again
15:18:03 <mgoddard> I guess we should add kolla-cli CI to the list
15:18:24 <mnasiadka> yoctozepto: don't worry, you fixed a deprecated feature :)
15:18:43 <hrw> can kayobe guys clean line 135+ in whiteboard?
15:18:58 <hrw> now as you have review priority
15:20:41 <mgoddard> hrw: sure
15:20:41 <mgoddard> done
15:20:50 <hrw> thx
15:21:05 <mgoddard> need to do another round of stable backporting
15:21:16 <mgoddard> last checked about 6 weeks ago
15:21:41 <mgoddard> #action mgoddard or someone else to check stable backports
15:22:18 <mgoddard> #topic Kayobe Stein release status
15:22:52 <mgoddard> Now that kolla stein has been released we have no excuses in kayobe, and should also release
15:23:10 <hrw> ;P
15:23:41 <mgoddard> dougsz, jovial[m], priteau: I marked a few patches as RP+1, I'd like to try getting these into master before we branch
15:23:57 <mgoddard> https://tiny.cc/kayobe-review-dash
15:24:06 <dougsz> will take a look, thanks
15:24:18 <jovial[m]> I'll take a look as soon as possible
15:24:30 <mgoddard> thanks
15:25:05 <mgoddard> #topic Train release planning
15:25:41 <mgoddard> yoctozepto and I were discussing earlier that Train is fast approaching
15:26:43 <mgoddard> feature freeze is september 13th, we normally freeze a few weeks after - so end of september
15:26:55 <mgoddard> #link https://releases.openstack.org/train/schedule.html
15:27:39 <mgoddard> it seems like a good time to reflect on our priority features
15:27:51 <mgoddard> L133 in https://etherpad.openstack.org/p/KollaWhiteBoard
15:28:07 <mgoddard> Anyone know the status of CentOS 8?
15:28:31 <mgoddard> https://wiki.centos.org/About/Building_8
15:28:52 <mgoddard> looks like they are quite far through, but I don't know how long they normally tak
15:29:23 <mgoddard> we are dependent on it for python3 on centos
15:29:42 <mgoddard> I expect we'll have a last minute push
15:30:20 <mnasiadka> most likely, and then RDO will send another pack of nails for our coffin :)
15:30:42 <mgoddard> ;)
15:31:01 <jovial[m]> also interesting was RHEL 7.7 with inplace kernel upgrades
15:31:02 <mgoddard> not much we can do there, unless we try using fedora
15:31:32 <mgoddard> jovial[m]: i.e. no reboot?
15:31:39 <mnasiadka> mgoddard: there is some f28 change by someone from RedHat, but I don't know the status
15:31:58 <jovial[m]> mgoddard: yeah - I believe that to the case
15:32:11 <mgoddard> mnasiadka: yeah, for kolla. Would be nice to have a kolla-ansible run with py3
15:32:49 <mgoddard> Ok, I guess we just wait on this one
15:32:54 <mnasiadka> mgoddard: ah, that one - shouldn't be hard to do a preliminary test
15:33:08 <mnasiadka> mgoddard: but who knows what won't work on CentOS 8 :)
15:33:29 <mgoddard> Define support matrix has not been started AFAIK
15:33:41 <mgoddard> anyone planning on picking it up?
15:33:55 <yoctozepto> support matrix is important but I'm too young core to handle this
15:34:00 <yoctozepto> ;p
15:34:06 <mgoddard> I vaguely remember someone saying they were interested, but they didn't get added as an owner
15:34:17 <yoctozepto> not me
15:34:30 <mnasiadka> yoctozepto: since you're the youngest core - you can create a framework, and then we can populate :)
15:34:47 <goldyfruit_> mgoddard, kplant no ?
15:34:58 <mgoddard> I think a lot of it will need collaboration, but as mnasiadka says someone needs to drive
15:35:19 <mgoddard> part of it is agreeing on vocabulary
15:35:50 <mgoddard> goldyfruit_: I added kplant as an owner, we can remove if he disagrees :)
15:36:12 <mgoddard> Nova cells is underway by dougsz
15:36:45 <kplant> it wasn't me :-)
15:37:26 <mgoddard> ok, removing kplant :)
15:37:35 <goldyfruit_> hum, my bad then´
15:37:51 <mgoddard> Support newer ansible versions: mnasiadka working on it
15:38:34 <mnasiadka> yup
15:38:34 <mgoddard> anything to say on it mnasiadka?
15:38:55 <mnasiadka> well, there are two changes - one for bumping up Ansible in kolla-toolbox
15:39:21 <mnasiadka> but in order to properly constrain pip packages versions in subsequent release branches - we need to use upper-constraints.txt
15:39:27 <yoctozepto> quick reject that was
15:39:29 <mnasiadka> which is not available in binary
15:39:46 <mnasiadka> so I need to rework some of the kolla/common/config.py stuff - should be ready this week
15:40:49 <mnasiadka> then another piece of work is migrating from kolla_* Ansible modules to upstream os_* - where it makes sense
15:40:54 <mnasiadka> but it's like an extra thing to do
15:40:57 <mgoddard> is this to include get upper-constraints for binary?
15:41:19 <mgoddard> how would you do it? curl the official URL?
15:41:35 <mgoddard> e.g. https://releases.openstack.org/constraints/upper/master
15:41:43 <mnasiadka> mgoddard: yeah, that was the idea - but then we need to have a variable that points to current openstack release :-)
15:41:49 <mgoddard> right
15:41:58 <mgoddard> ok, thanks
15:41:59 <goldyfruit_> (mgoddard, it was ohwhyosa)
15:42:09 <mgoddard> aha, nice one goldyfruit_
15:43:18 <mgoddard> Debian/Ubuntu Python 3 support is mostly done, but there is a bug in kolla-ansible that shows we need some changes there too
15:43:40 <mgoddard> hrw: https://review.opendev.org/#/c/674241/
15:43:56 <mgoddard> python path stuff
15:44:02 <hrw> will look
15:44:08 <mgoddard> thanks
15:44:26 <mgoddard> TLS everywhere has a number of patches in flight, kklimonda working on it
15:44:31 <mgoddard> what's the status kklimonda?
15:44:53 <yoctozepto> he was not around
15:45:20 <mgoddard> patches need updating IIRC
15:46:12 <mgoddard> libvirt TLS needs another review
15:46:18 <mgoddard> and merge conflicts fixing
15:47:10 <mgoddard> [kolla] Health checks
15:47:16 <mgoddard> mnasiadka: started looking at it?
15:47:48 <mnasiadka> mgoddard: yes, had some preliminary code somewhere, will look into that after Ansible bump up
15:48:04 <mgoddard> k
15:48:24 <mgoddard> [kolla ansible] Improving test coverage
15:48:36 <mgoddard> lots of good stuff done here already
15:48:43 <mgoddard> a few more in progress
15:49:02 <mgoddard> dougsz: would be nice to get an intial monasca test merged that we can iterate on
15:49:28 <dougsz> ah yes, sorry, I need to debug why it is failing
15:49:34 <mnasiadka> mgoddard: I was thinking the same about prometheus and all those exporters that we have...
15:49:49 <mnasiadka> I mean if somebody would like to do it :)
15:50:09 <mgoddard> yeah, would be nice to have that covered
15:50:28 <mgoddard> Simplifying handler conditionals - done
15:50:38 <mgoddard> [kolla] Podman/buildah support - no owner yet
15:50:59 <mgoddard> [kolla ansible] IPv6 - yoctozepto have you started it?
15:51:10 <hrw> I am afraid that podman thing will slip into Ucycle
15:51:35 <yoctozepto> mgoddard: yeah, sketching
15:51:37 <mgoddard> hrw: I expect so. It's low on priorities so that's ok
15:51:40 <hrw> BaptisteGer is working on ipv6 deployment in Linaro. no idea how much time during week he has for it
15:51:42 <mgoddard> yoctozepto: cool
15:51:54 <mgoddard> hrw: using kolla ansible?
15:51:57 <hrw> mgoddard: yes
15:52:10 <mgoddard> cool yoctozepto & BaptisteGer should talk :)
15:52:15 <yoctozepto> yeah, he sent me his diff
15:52:20 <mgoddard> nice
15:52:38 <mgoddard> hrw: can I add BaptisteGer as another owner of that feature or is it just downstream?
15:52:41 <yoctozepto> obviously it drops ipv4 support the way he did it :-)
15:52:52 <mgoddard> lol
15:53:01 <yoctozepto> ipv6 only man
15:53:03 <mgoddard> got to start somewhere
15:53:04 <yoctozepto> done right
15:53:18 <hrw> mgoddard: add as interested rather than owner
15:53:35 <yoctozepto> I will bother him to test my proposal when ready
15:53:36 <mgoddard> hrw: done
15:53:45 <hrw> yoctozepto: he may base on some old patch which did that way
15:53:57 <hrw> and it is easier to get ipv6 machines than ipv4 ones
15:54:21 <yoctozepto> the diff is good for scoping, no problem
15:54:38 <mgoddard> [kolla ansible] Upgrade checkers - no progress since PoC
15:55:05 <mgoddard> [kolla] Define source image config via JSON - I think mnasiadka picked this up
15:55:30 <mgoddard> mnasiadka: if it has a bug/blueprint, please link it on the whiteboard
15:55:41 <mgoddard> [kolla ansible] SELinux - needs an owner
15:56:01 <mnasiadka> mgoddard: yes, as I wandered into the abyss called common/config.py - but I will most probably first fix the Ansible bump up to make it fast, and then continue with the JSON stuff later on - if that's ok
15:56:14 <mgoddard> sure
15:56:28 <mgoddard> ok let's move on in the last few minutes
15:56:30 <yoctozepto> I have working selinux experience but not willing to be blamed for failing the delivery :-)
15:56:32 <mnasiadka> if SELinux doesn't have an owner now - it will be hard to get anywhere before end of Sep
15:56:40 <mgoddard> hopefully that was useful though
15:56:53 <yoctozepto> add as potential owner or sth
15:56:56 <mgoddard> well sdake claimed it used to 'just work' :)
15:57:05 <yoctozepto> could be
15:57:12 <mnasiadka> mgoddard: it did, but neutron-ovs-agent stopped working long time ago
15:57:15 <mgoddard> tripleo does it with kolla images
15:57:16 <yoctozepto> docker is free of selinux checks most likely
15:57:34 <mnasiadka> mgoddard: yes, but they don't use libvirt and ovs in container :)
15:57:44 <mgoddard> #topic: Ocata EOL
15:57:54 <mgoddard> Who wants to EOL ocata?
15:58:04 <mgoddard> We have waited the required 6 months with failing CI
15:58:24 <mnasiadka> I think the question should be who wants to keep it alive :-)
15:58:51 <mgoddard> I guess so
15:58:58 <mgoddard> anyone want to keep it alive?
15:59:22 <yoctozepto> I want to EOL pike
15:59:25 <yoctozepto> don't look at me
15:59:49 <mgoddard> can't EOL pike until CI has been failing for 6 months :)
15:59:53 <mnasiadka> yeah, I wanted to point out that pike is EM (or should be)
15:59:54 <mgoddard> officially
15:59:59 <hrw> ocata is dead.
16:00:11 <mgoddard> ok I think we agree on EOL ocata
16:00:20 <hrw> for me <queens is dead. queens is dead. rocky is what we still have in use
16:00:34 <mgoddard> we still need to keep queens alive
16:00:41 <yoctozepto> queens is dead, long live rocky?
16:00:42 <mgoddard> until EM
16:00:58 <mgoddard> #topic Shanghai summit
16:01:04 <mgoddard> Anyone going?
16:01:17 <goldyfruit_> I'll try
16:01:18 * hrw skips
16:02:10 <mgoddard> goldyfruit_: would you be available to help with kolla forum sessions e.g. answering questions etc.?
16:02:31 <mgoddard> spsurya has agreed to handle the project update and project onboarding as I won't be going
16:02:43 <mgoddard> with help from Jeffrey4l_ and colleagues
16:02:55 <goldyfruit_> mgoddard, If I'm going yes
16:03:01 <nafiux> I want to get more involved on kolla project in general, will start reading the https://docs.openstack.org/kolla/latest/contributor/index.html before asking questions on how everything is getting organized :)
16:03:23 <hrw> nafiux: wait for open discussion part
16:03:39 <nafiux> Sure!
16:04:19 <mgoddard> we're over time on the meeting, does anyone need to go or can we finish off?
16:04:53 <yoctozepto> mgoddard: rafaelweingartne
16:04:59 <rafaelweingartne> is it the open discussions moment?
16:05:20 <rafaelweingartne> I was waiting for it
16:05:31 <mgoddard> Let's discuss Ceph ansible migration next time (or after meeting in channel)
16:05:32 <yoctozepto> yeah, the meeting was a bit longer than usual
16:05:37 <mgoddard> #topic open discussion
16:05:46 <mgoddard> rafaelweingartne: you're up
16:06:30 <rafaelweingartne> ok, so I have been working on this PR (https://review.opendev.org/#/c/670626/) ``Standardize the configuration of "oslo_messaging" section``
16:06:53 <rafaelweingartne> and we have had some debate regarding the use of those "oslo_messaging" sections
16:07:31 <rafaelweingartne> our team here, when we first used Kolla-ansible, we expected it to deploy a minimum viable openstack setup, which in our perspective should include event messaging
16:08:14 <mgoddard> I guess 'minimum viable' is open to interpretation :)
16:08:16 <rafaelweingartne> just when we were debugging an bug that is caused by Ceilometer and barbican keystone listener, when they are using the same topic that we found out what was happening
16:08:28 <rafaelweingartne> mgoddard: yes
16:08:31 <hrw> rafaelweingartne: those notifications goes to ceilometer, right?
16:08:41 <rafaelweingartne> yes and no
16:08:46 <rafaelweingartne> there are some misconfigurations
16:09:03 <hrw> I mean 'notifications require ceilometer'
16:09:15 <rafaelweingartne> for instance, barbican cannot connect to the same topic. Otherwise, it will get events that were not destinated to it
16:09:16 <yoctozepto> hrw: no
16:09:38 <yoctozepto> hrw: ceilometer is just the main consumer
16:09:43 <hrw> ok
16:09:48 <rafaelweingartne> hrw: yes, that is our interpretation, but there is nothing hardcoded, all of it can be customized, and some projects do that
16:10:37 <hrw> rafaelweingartne: ok
16:10:38 <openstackgerrit> gugug proposed openstack/kolla-cli master: Move kolla prechecks action into kolla_actiom model  https://review.opendev.org/675140
16:10:40 <rafaelweingartne> so, after discussing with Radek, and later with Mark, we proposed to apply the same method that was being used in Nova role in all of the other projects that had the oslo messaging section declared, but not configured
16:11:28 <rafaelweingartne> just to give you guys a quick highlight of that idea, in Nova we can decide if oslo_messaging is going to be configured if there are at least of topic enabled
16:11:48 <rafaelweingartne> and then, the topics are enabled/disabled based on components that are enabled/disabled (e.g. ceilometer)
16:12:53 <rafaelweingartne> What I think we need to discuss here is: "do we have an idea what are the projects that need notifications so the deployment can be considered an MVP?"
16:13:34 <rafaelweingartne> by asking that, I am assuming that the method/standard applied in Nova role is widely accepted by the community, and therefore, we just need to discuss where to apply it
16:13:43 <yoctozepto> well, it seems ceilometer can be configured to listen for any project's notifications
16:13:50 <rafaelweingartne> yes
16:13:59 <yoctozepto> so we can coordinate that as well
16:14:12 <yoctozepto> and then configure any service that:
16:14:15 <yoctozepto> 1) exists?
16:14:24 <yoctozepto> 2) we know produces notifications?
16:14:30 <yoctozepto> ^ choose one
16:14:44 <mgoddard> I would say 2
16:14:48 <rafaelweingartne> well, I was not aware of all of the projects that produced notifications
16:15:04 <rafaelweingartne> therefore, I just went to the roles, and looked for the ones that had the "oslo_messaging" section declared
16:15:22 <rafaelweingartne> and worked to configure them using the approach I described
16:15:39 <rafaelweingartne> but sure, we can extend this to all service that push some notification
16:16:45 <mgoddard> I would more say "restrict" this to services that push notifications
16:16:59 <yoctozepto> +1 to mgoddard way
16:17:03 <rafaelweingartne> all of them then?
16:17:07 <yoctozepto> review the modified services
16:17:11 <yoctozepto> it should be easier
16:17:31 <yoctozepto> and drop the notifications for those that do not produce them for sure
16:17:34 <mgoddard> for example, I don't believe mistral produces notifications, so we should not add variables for it
16:17:41 <rafaelweingartne> because right now, we seem to be enabling notifications in just a few (more than a few actually) of them
16:17:42 <mgoddard> (I am open to being proven wrong)
16:18:14 <rafaelweingartne> and regarding the drop of the oslo messaging sections
16:18:18 <yoctozepto> rafaelweingartne: the thing is none of current cores was responsible for notifications integration in k-a
16:18:29 <rafaelweingartne> hmm
16:18:42 <rafaelweingartne> got it
16:18:46 <yoctozepto> so we cannot say why it was done this way
16:18:57 <yoctozepto> might be copy-paste syndrome
16:18:59 <rafaelweingartne> yes, this caused a bit of confusion for us
16:19:11 <rafaelweingartne> it actually looked quite a lot of copy/paste indeed
16:19:46 <rafaelweingartne> and that is why we decided to fix it by apply the same standard that we have in some well-known project roles such as the nova one
16:20:30 <rm_work> dropping in randomly, but as an example, Octavia should have an oslo_messaging configuration section, but we don't produce notifications (we just READ from a queue -- which I think is the same for a lot of projects?)
16:20:31 <mgoddard> I think we agree that is a good approach, we just need to review where we apply it
16:20:43 <rm_work> apologies if I missed some context
16:20:55 <rafaelweingartne> yes, but this is a problem
16:21:06 <rafaelweingartne> for instance for the projects that had the section declared, but did not use it
16:21:11 <mgoddard> rm_work: that is very good context, and one reason why I was concerned about removing these sections
16:21:13 <rafaelweingartne> should I do the removal in the same PR?
16:21:25 <rafaelweingartne> or should I wait and do that in a different one?
16:21:37 <mgoddard> rafaelweingartne: based on rm_work's comment, please do not remove any oslo_messaging_notification sections
16:21:37 <rafaelweingartne> I would rather do in a second PR just with the removals
16:21:44 <yoctozepto> I thought the section configured producers, not consumers
16:21:53 <rm_work> ahh hold on
16:22:08 <rm_work> I just read this:
16:22:08 <rm_work> [09:15:04] rafaelweingartne:	therefore, I just went to the roles, and looked for the ones that had the "oslo_messaging" section declared
16:22:10 <rafaelweingartne> me too
16:22:25 <rm_work> if it's [oslo_messaging_notifications], then that's maybe fine, we don't declare that
16:22:31 <mgoddard> rm_work: ok, thanks
16:22:34 <rm_work> but i am not sure if it's relevant for readers-only
16:22:35 <yoctozepto> thanks rm_work
16:22:54 <yoctozepto> lemme check then, but I'm 99% sure it is for producers only
16:22:57 <mgoddard> I'm still a little wary of removing them
16:23:17 <mgoddard> if we can verify it's only used for producers I would be less wary
16:23:18 <rafaelweingartne> yoctozepto: I checked, and it was for producers only
16:23:29 <rafaelweingartne> but I am quite new to openstack, so I might be mistaken
16:23:43 <mgoddard> either way, separate PR please
16:23:51 <yoctozepto> https://docs.openstack.org/oslo.messaging/stein/configuration/opts.html#oslo-messaging-notifications
16:24:07 <yoctozepto> *sending*
16:24:09 <mgoddard> ok we're approaching 30 minutes over time in the meeting. The discussion can continue in here if people are free
16:24:14 <mgoddard> Thanks everyone
16:24:14 <rm_work> cool, just got concerned due to the abbreviation :D
16:24:18 <mgoddard> #endmeeting