16:03:58 <mnaser> #startmeeting openstack_ansible_meeting
16:03:59 <openstack> Meeting started Tue Sep 18 16:03:58 2018 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:01 <prometheanfire> :P
16:04:02 <mnaser> #topic rollcall
16:04:03 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:04:06 <prometheanfire> o/
16:04:10 <cjloader> o/
16:04:45 <mnaser> o/
16:05:07 <spotz> o/ - but ping if needed in case I squirrel off:)
16:05:51 <mnaser> #topic Last week highlights
16:05:54 <mnaser> we were at the ptg last week
16:06:03 <mnaser> so we didn't hold a meeting
16:06:19 <mnaser> it was super productive, most of the stuff we tried to talk about were jotted down here -- https://etherpad.openstack.org/p/osa-stein-ptg
16:06:49 <mnaser> i see a lot of green there which was me taking notes, if anyone wants to go over those that'd be good in case i misunderstood things :)
16:07:29 <odyssey4me> :)
16:07:42 <mnaser> other than that i'm super excited for teh upcoming cycle
16:07:52 <mnaser> it will be a cycle of a lot of deleted code :D
16:07:52 <mnaser> haha
16:07:53 <guilhermesp> mnaser: how about kafka stuff?
16:08:04 <mnaser> guilhermesp: sure!  ansmith
16:08:12 <mnaser> might want to comment on that
16:08:36 <mnaser> we can help out with getting the stuff imported into openstack gerrit, get some basic gating in place
16:08:44 <mnaser> and then that can we be used for an alternative messaging job
16:08:54 <guilhermesp> as I mentioned in the ehterpad. That one that we use for monasca is in my github just because other are pretty stale
16:09:06 <mnaser> maybe wait for ansmith's +1 and if he sees value then we can add it
16:09:10 <guilhermesp> but if you guys thinks will be good to more to osa namespace we can work on it
16:09:39 <mnaser> i'm not opposed to adding it under the group of things we manage, it makes it easier, it also means that we can add it to CI and have it as a deliverable, we can add it with it's own core team that's a subset of osa-core and you'd be on it guilhermesp
16:10:02 <mnaser> thoughts?
16:10:06 <odyssey4me> yup, ansible-role-kafka - then keep it generally useful and not OSA specific
16:10:19 <evrardjp> agreed
16:10:23 <guilhermesp> I think is a better approach
16:11:05 <guilhermesp> I will just need to use that one as a start point
16:11:16 <mnaser> guilhermesp: yes, it's possible to import an existing project
16:11:21 <guilhermesp> as it is designed to work along monasca rola
16:11:32 <guilhermesp> role*
16:11:42 <waynr> o/
16:11:42 <mnaser> guilhermesp: do you want to work on importing the project? https://docs.openstack.org/infra/manual/creators.html
16:11:56 <odyssey4me> guilhermesp: sure, it'll likely need some rework, but that can happen in time
16:12:12 <guilhermesp> mnaser: sure I do
16:12:28 <mnaser> cool, please ping me on any reviews on that (it'l llikely require a ptl+1 anyways)
16:12:52 <guilhermesp> k mnaser
16:12:56 <odyssey4me> guilhermesp: you'll find, for example, the os_neutron role has an independent core team - so you can model from it
16:13:07 <odyssey4me> for the gerrit config I mean
16:13:11 <mnaser> ^ yep, that too
16:13:39 <guilhermesp> cool I will need some guidance  to do it but I'm pretty sure can be done by my side
16:14:55 <Tahvok> Hey guys! Just wanted to say a few words. Unfortunately, I have moved to other company, and won't be dealing with openstack anymore. Anyway, I just wanted to say thank you all for supporting me, and guiding me trought this awesome project. It was really nice working with you, and even meating some of you at the ptg event, and hopefully we'll meet someday again, maybe it'll be openstack event again,
16:14:56 <Tahvok> who knows. Thanks for everything!
16:15:16 <mnaser> Tahvok: thank you <3
16:15:24 <mnaser> don't be a stranger!
16:15:36 <odyssey4me> o/ Tahvok - thanks for helping us out and best wishes as you move on to your next adventure!
16:16:34 <mnaser> guilhermesp: cool well please let me know if you need any help with moving it
16:16:40 <mnaser> #topic bug triage
16:16:55 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1792050
16:16:55 <openstack> Launchpad bug 1792050 in openstack-ansible "SELinux context overrides fail for neutron install on metal" [Undecided,New]
16:17:25 <mnaser> eh
16:17:34 <mnaser> should we just remove the selinux stuff because we don't support it right now anyways?
16:17:44 <odyssey4me> argh, just delete it and port all the deletes back as far as they go
16:17:47 <mnaser> just like swift
16:17:57 <mnaser> guilhermesp: can you take this please? i know it's affected us a few times
16:18:05 <guilhermesp> sure
16:18:14 <mnaser> so confirmed/medium/assign to guilhermesp
16:18:33 <odyssey4me> it's not like mhayden even likes having setenforce 1 ;)
16:18:47 <mnaser> yeah we have to ping him everytime we pull selinux code out
16:18:47 <mnaser> ha
16:19:03 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1791873
16:19:03 <openstack> Launchpad bug 1791873 in openstack-ansible "Keystone LDAP tasks fail because haproxy pool is drained during install" [Undecided,New]
16:19:14 <odyssey4me> given he runs openstack on centos, it's the least we can do ;)
16:20:01 <odyssey4me> oh bother, that's a pain
16:20:28 <odyssey4me> we'll have to make it do that set of tasks on the last of the keystone hosts so that it has an endpoint to speak to
16:20:32 <odyssey4me> I'll pick that up
16:20:39 <mnaser> cool, thanks odyssey4me
16:20:54 <mnaser> done!
16:21:56 <odyssey4me> oh nice, it's using our old module - so this is another little bit of tech debt to clean up
16:22:09 <mnaser> sweet
16:22:18 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1791258
16:22:18 <openstack> Launchpad bug 1791258 in openstack-ansible "Make use of ansible-config_template repo" [Undecided,New]
16:22:54 <mnaser> ugh darn
16:22:57 <mnaser> the code is diverged too
16:22:59 <mnaser> no bueno
16:23:18 <mnaser> jrosser: given you commented do you have some spare time? :p
16:23:22 <odyssey4me> evrardjp: had a plan for this
16:25:07 <mnaser> evrardjp: a plan with time to do it or? :p
16:25:26 <evrardjp> good point
16:25:52 <evrardjp> I will document the plan if I cannot work on this next week-end
16:26:08 <evrardjp> is that okay for you?
16:26:36 <mnaser> evrardjp: seems reasonable, can we assign to you and then if time is a thing we can reassign?
16:27:07 * jrosser back
16:27:23 <evrardjp> mnaser: fine for me
16:27:40 <jrosser> it all blew up for me with the elk stuff which calls up the seperate repo, that had/has a bug with json templating
16:27:50 <mnaser> jrosser: i had the same issue i think
16:28:01 <jrosser> need to be careful when bringing the code into line not to pollute the good code with that
16:28:09 <jrosser> and also it probably means there is a missing test
16:28:11 <mnaser> god dang, my mouse battery is dying aha
16:28:15 * mnaser will be slower
16:28:25 <mnaser> um
16:28:28 <mnaser> im getting a big error
16:28:31 <mnaser> setting that bug to confirmed
16:28:35 <mnaser> anyone else can do it?
16:30:30 <mnaser> please? :>
16:30:40 <mnaser> i'm getting a big blob of red error text.
16:31:13 <jrosser> done
16:31:21 <mnaser> thats weird
16:31:23 <mnaser> i guess its something on my side
16:31:32 <mnaser> yeah i cant set anything it keeps giving me errors
16:31:33 <mnaser> gah
16:31:50 <mnaser> ok switcihng browsers worked
16:32:10 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1791085
16:32:10 <openstack> Launchpad bug 1791085 in openstack-ansible "OVN Metadata Service Broken" [Undecided,New]
16:32:26 * mnaser ping jamesdenton
16:33:05 <prometheanfire> related to ceilometer?
16:33:07 <mnaser> and maybe cloudnull because that is related to teh thing that broke it
16:33:17 <mnaser> no OVN + os_neutron
16:33:20 <mnaser> https://github.com/openstack/openstack-ansible-os_neutron/commit/d6481ef9fcfc85ff931317b6f16bdac43cbb6488#diff-2444ad0870f91f17ca6c2a5e96b26823
16:33:32 <prometheanfire> nope, shutting-up :D (there was another ovn issue upstream)
16:33:35 <prometheanfire> reqs wise
16:35:17 <mnaser> i think given that both who are involved aren't around
16:35:23 <mnaser> ill leave it there so we review it next week
16:35:35 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1790933
16:35:35 <openstack> Launchpad bug 1790933 in openstack-ansible "Implement OVSDB clustering for OVN" [Undecided,New] - Assigned to James Denton (james-denton)
16:36:16 <mnaser> looks like this is to track a bug
16:36:17 <mnaser> and already assigned
16:36:37 <mnaser> to maybe in progress / medium
16:38:47 <evrardjp> mnaser: jamesdenton generally works like that -- let him the time and new feature shall appear :)
16:39:00 <mnaser> yeah i guess no one else opposes to that
16:39:11 <mnaser> #link https://bugs.launchpad.net/openstack-ansible/+bug/1790779
16:39:11 <openstack> Launchpad bug 1790779 in openstack-ansible "delegate_to on deploying host uses dns?" [Undecided,New]
16:39:58 <mnaser> hwoarang: or logan- might chime on this?
16:40:17 <hwoarang> hmm
16:40:23 <mnaser> afaik this should use the physical_mapping thing no?
16:40:43 <logan-> yes one sec
16:41:00 <logan-> i hit this on pike last week
16:41:02 <evrardjp> interesting, is it the case of delegation to something not in the inventory that triggers?
16:41:03 <logan-> it is broken as of https://github.com/openstack/openstack-ansible/commit/a8a809839484105d9cd27463defc19a8a617c64b#diff-db999e390dd84f2a8c2a48b19aa9533f
16:41:31 <logan-> you can see it on a prod deploy here: http://logs.openstack.org/e9/e957a7dc2fd07f86bc2ab60dd25e00504c705eca/post/limestone-ci-deploy/705562f/
16:41:41 <evrardjp> oh god it's loop_var that causing the issue?
16:41:43 <hwoarang> reporter does not say what version it is
16:41:48 <logan-> http://logs.openstack.org/e9/e957a7dc2fd07f86bc2ab60dd25e00504c705eca/post/limestone-ci-deploy/705562f/logs/ara-report/result/45ed4626-65ca-4b65-a4c4-d39cf32eaadf/
16:41:57 <jamesdenton> mnaser pong
16:42:02 <hwoarang> i thought the interpolation of loop_var was fixed by the recent commit in the plugins repo
16:42:23 <logan-> hwoarang: i was hoping that backporting your change to the other branches would solve this, but it did not in pike
16:42:30 <openstackgerrit> Jacob Wagner proposed openstack/openstack-ansible-ops master: Add ability to deploy Ceph into a Multinode AIO  https://review.openstack.org/585003
16:42:48 <openstackgerrit> Jesse Pretorius (odyssey4me) proposed openstack/openstack-ansible-os_keystone master: Implement LDAP domains using last keystone host  https://review.openstack.org/603440
16:43:18 <hwoarang> we should clarify on the bug what is the OSA version that he is using
16:43:20 <evrardjp> debug of https://github.com/openstack/openstack-ansible-plugins/blob/master/strategy/linear.py#L138-L147 would help I guess
16:43:20 <logan-> that build used dc4abed00960c0123d45e9e67e666a5e9a1bb51f from plugins http://logs.openstack.org/e9/e957a7dc2fd07f86bc2ab60dd25e00504c705eca/post/limestone-ci-deploy/705562f/job-output.txt.gz#_2018-09-17_19_32_59_217416
16:43:25 <hwoarang> because master and rocky should be ok
16:43:37 <logan-> which is your fix: https://github.com/openstack/openstack-ansible-plugins/commits/stable/pike
16:43:49 <evrardjp> hwoarang: do we have the loop_var in testing?
16:43:56 <hwoarang> prob not
16:44:03 <odyssey4me> we do not, because there is only one cluster member
16:44:14 <hwoarang> but in opnfv we use rocky with multinode and it's ok (so we are using the loop_var thing)
16:44:15 <odyssey4me> we should add one to the plugins repo I guess
16:44:22 <mnaser> jamesdenton: we can discuss after this issue :>
16:44:33 <jamesdenton> yep - will sync up later
16:44:42 <evrardjp> hwoarang: ok
16:45:15 <openstackgerrit> Jesse Pretorius (odyssey4me) proposed openstack/openstack-ansible-os_keystone master: Implement LDAP domains using last keystone host  https://review.openstack.org/603440
16:45:36 <mnaser> so what do we do about this bug?
16:46:05 <openstackgerrit> Markos Chandras (hwoarang) proposed openstack/openstack-ansible-os_keystone master: SUSE: Add support for openSUSE Leap 15  https://review.openstack.org/603114
16:46:15 <logan-> i don't know the fix yet, but it clearly exists in pike, not sure about ocata or queens, hwoarang says rocky is fixed and we can presume master is probably ok if rocky works
16:46:33 <hwoarang> mnaser: well based on what logan said it's ay it's confirmed but I would ask the reporter to at least provide the OSA version so we know what we are looking for
16:46:34 <odyssey4me> we either backout multiple fixes, and add a release note notifying people - or we add a test to expose it and fix it, and add a release note
16:47:10 <logan-> https://github.com/openstack/openstack-ansible/commit/a8a809839484105d9cd27463defc19a8a617c64b#diff-db999e390dd84f2a8c2a48b19aa9533f could be reverted and implemented differently
16:47:25 <logan-> rather than trying to fix plugins
16:47:51 <odyssey4me> or that
16:47:53 <mnaser> incomplete = ask for information such as release?
16:48:23 <evrardjp> I'd say so
16:48:24 <logan-> i will append the bug with this log so we can mark it confirmed on pike at least
16:48:31 <evrardjp> ok
16:48:38 <mnaser> logan-: cool wfm
16:49:10 <logan-> would be nice to know if queens is broken also
16:49:12 <mnaser> jamesdenton: going back to the ovn breakage, do you want to talk this over with cloudnull maybe to see if he can adjust the patch?
16:49:26 * hwoarang needs to run for a bit. bbl
16:50:00 <jamesdenton> yes, that's probably best. It looks like some of the other distros are handling it a little differently, by running OVS as non-root
16:50:31 <jamesdenton> so long term we may need to figure out something different for OSA
16:50:35 <jamesdenton> i can get with cloudnull
16:51:07 <mnaser> that'd be nice, ill leave it as is and we can follow up next week
16:51:11 <jamesdenton> sure
16:51:27 <mnaser> #topic open discussion
16:51:35 <mnaser> any pressing issues? :)
16:51:50 <cjloader> I have a follow up proposal
16:51:58 <mnaser> sure
16:52:15 <cjloader> for the https://review.openstack.org/#/c/556586/ designate spec we discussed last week
16:52:50 <spotz> That was quick cjloader:)
16:54:18 <cjloader> what if we provide an option to use bind and powerdns, to where we allow users to switch from one to another, we alrready have playbooks to install bind, but then can work to add powerdns later?
16:54:47 <prometheanfire> cjloader: those are test playbooks
16:55:22 <mnaser> also afaik mugsie mentioned powerdns is the 'better' driver subjectively
16:55:39 <evrardjp> I am not surprised
16:55:47 <jrosser> i linked to a WIP of mine that does a good deal of what the spec talks about, it consumes an external role for bind
16:56:01 <jrosser> which could be plugged for $dns-server of choice
16:56:45 <skiedude> Fun fact running the ./scripts/run-upgrade.sh in any branch (at least for queens, rockey, master) it always says " This script will perform a Pike to Queens upgrade."
16:57:10 <cjloader> yes, but not fully tested though, bind has been tested on a PR basis
16:57:32 <evrardjp> skiedude: haha I see a patch incoming then :)
16:57:51 <skiedude> I assume you'd need to patch that in every branch, no? evrardjp
16:57:54 <evrardjp> thanks skiedude for noticing and the patch :)
16:58:00 <evrardjp> skiedude: yup
16:58:18 <mnaser> prometheanfire: what do you feel about what cjloader proposes?
16:58:20 <evrardjp> but let's start with master :)
16:58:25 <evrardjp> I have to run
16:58:33 <evrardjp> thanks mnaser and everyone
16:59:14 <prometheanfire> mnaser: about choice?  I personally feel like powerdns should be focussed on first, simply because working with upstream is better, once that works move to bind (which role is not published iirc)
16:59:24 <noonedeadpunk> evrardjp: if you wish to save your time, I can manage with that
16:59:40 <mnaser> i agree with prometheanfire on this
16:59:57 <odyssey4me> Personally, I don't really see how someone would 'switch from one to the other' simply - but having an option for either is fine. If it's destined to be on the same host, then including it in the same role is fine - but I suspect people may want to put DNS on its own host, different to the designate service... so it probably makes better sense to have the role execute in a playbook instead.
17:00:40 <prometheanfire> iirc designate will repopulate the server if the backend is switched
17:00:46 <cjloader> okay, powerdns first then
17:00:50 <prometheanfire> but I don't see switching 'live' as a common thing
17:01:13 <cjloader> i'm not saying switch live
17:01:44 <cjloader> i'm saying have a variable that will pull each respective role
17:01:50 <cjloader> if set
17:02:05 <mnaser> yeah i think thats' what we agreed on / thats what odyssey4me suggested
17:02:06 <odyssey4me> I'm suggesting that making that promise is a hard one to keep, so don't make it. Support one back-end first, then support a second. If people want to migrate from one to the other, it's up to them to test and do so.
17:02:15 <mnaser> but the first one we'd do would be powerdns
17:02:23 <odyssey4me> yes, definitely
17:02:25 <cjloader> okay
17:02:33 <cjloader> sounds good
17:02:57 <mnaser> cool, any other subjcets? :)
17:03:05 <mnaser> (we're up on time anyways)
17:03:17 <odyssey4me> I'd like to propose pulling https://review.openstack.org/#/q/topic:remove-mysql-python+(status:open+OR+status:merged) as far back as pike.
17:03:34 <mnaser> im +1
17:03:44 <odyssey4me> We've been using pymsql a long time, and most of that is just cleaning/tidying up.
17:03:51 <prometheanfire> didn't we change to pymysql?
17:03:53 <prometheanfire> ya
17:03:57 <odyssey4me> But doing this will also probably reduce run time considerably.
17:04:24 <odyssey4me> I think we moved to pymysql as far back as liberty.
17:04:26 <mnaser> and increase stabiltiy imho. i'm all for it
17:05:04 <odyssey4me> ok, I'll do the backport proposals tomorrow - please look out for them, it'd be best if we get them all in quickly rather than end up with a mix and match in a release.
17:05:12 <mnaser> ++ i will do that too
17:05:32 <mnaser> alright, that is pretty much it i think
17:05:34 <mnaser> thats everyone
17:05:35 <mnaser> #endmeeting