16:01:14 <evrardjp> #startmeeting openstack_ansible_meeting
16:01:15 <openstack> Meeting started Tue Oct 10 16:01:14 2017 UTC and is due to finish in 60 minutes.  The chair is evrardjp. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:20 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:22 <Taseer> evrardjp: ok, sure.
16:01:22 <evrardjp> #topic rollcall
16:01:32 <evrardjp> o/
16:01:41 <hwoarang> #info hwoarang
16:01:53 <evrardjp> #info hwoarang
16:02:04 <evrardjp> that's interesting.
16:02:06 <andymccr> o/ - here partly
16:02:20 <evrardjp> ok we have quorum, let's start.
16:02:24 <hwoarang> lol
16:02:26 <evrardjp> :p
16:02:44 <evrardjp> If anyone wants to handle bug triage in the future, that would be great.
16:03:08 <evrardjp> #topic new bugs
16:03:15 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1722273
16:03:15 <openstack> Launchpad bug 1722273 in openstack-ansible "haproxy_keepalived_vars_file not overriding keepalived configuration" [Undecided,New]
16:04:03 <evrardjp> that sounds valid docs issue
16:04:22 <evrardjp> and I am probably the one to blame.
16:04:29 <evrardjp> but let's skip that part.
16:04:32 <evrardjp> :D
16:04:54 <evrardjp> confirmed, but what level? IMO we are setting wrong expectations, so I'd put it as high
16:05:12 <hwoarang> ok
16:05:46 <evrardjp> spotz: do you have time to look at this one?
16:06:17 <evrardjp> next
16:06:19 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1722200
16:06:20 <openstack> Launchpad bug 1722200 in openstack-ansible "percona-xtrabackup unmet dependencies" [Undecided,New]
16:07:21 <evrardjp> andymccr: the docs for the upgrade is still manually updated, right? It's not coming from the upgrade script or anything
16:07:24 <hwoarang> hmm
16:07:48 <andymccr> the docs for the upgrade?
16:08:04 <andymccr> they arent automatically updated anyway i know of at least
16:08:09 <evrardjp> ok
16:08:21 <evrardjp> maybe it's out of sync with the code
16:08:35 <evrardjp> but also we don't test this in our periodics...
16:08:42 <evrardjp> so we might have missed it
16:09:39 <andymccr> we dont do db upgrades in the os upgrade?
16:09:40 <andymccr> yeah
16:09:45 <andymccr> tbh i think those 2 things should be separate
16:09:58 <andymccr> if you want to update your DB go for it, we have a process for that, but it isn't specifically tied into openstack itself
16:10:37 <evrardjp> oh you mean completely removing the db part of the maintenance, and do it separately?
16:10:54 <andymccr> i mean that would be up for debate
16:10:55 <odyssey4me> in our run_upgrade script we do implement the flag to upgrade the DB
16:10:56 <andymccr> but i personally think so
16:11:04 <andymccr> oh so we do an upgrade test during the upgrade scenarios?
16:11:08 <andymccr> in that case. sure
16:11:15 <odyssey4me> yes, one should do it seperately, but that's why we outline all the steps and recommend you do them manually
16:11:20 <andymccr> i mean i still think the 2 are separate
16:11:24 <andymccr> i wouldnt advise doing a db upgrade during your openstack upgrade
16:11:26 <andymccr> but thats just me :)
16:11:27 <evrardjp> andymccr: yes we do test it, but not this one particularily because we don't test N to O
16:11:38 <andymccr> evrardjp: don't we? i thought we had an ocata upgrade scenario
16:11:41 <odyssey4me> we do test N to O
16:11:47 <evrardjp> mmm
16:11:55 <andymccr> i think i checked last time and it was working too - but could be wrong
16:12:02 <odyssey4me> the periodic upgrade test for 'ocata' is an upgrade to Ocata
16:12:17 <odyssey4me> and yes, it's been reliably working for some time
16:12:27 <evrardjp> it doesn't show up on health
16:12:38 <odyssey4me> the galera_server repo also does a cluster upgrade per commit for the newton/ocata branches IIRC
16:12:41 <evrardjp> oh maybe we don't generate subunit for it?
16:12:52 <odyssey4me> no subunit for any branches older than pike
16:12:59 <evrardjp> ok
16:13:03 <evrardjp> that's it
16:13:19 <odyssey4me> http://logs.openstack.org/periodic/periodic-openstack-ansible-upgrade-aio-ocata-ubuntu-xenial/
16:14:06 <odyssey4me> the latest one succeeded
16:15:01 <odyssey4me> this issue may be due to using the percona repo instead of the downloaded package?
16:15:13 <odyssey4me> not sure - the issue will need confirming
16:15:27 <odyssey4me> we know that the defaults aren't showing that failure though due to the periodics
16:15:35 <evrardjp> yeah, so what concerns me there is the version
16:15:42 <evrardjp> 2.3 instead of 2.4
16:16:27 <evrardjp> on the job you see it tries to install 2.4 from 2.3 and it works
16:16:41 <evrardjp> I will check with armaan in more details tomorrow I guess
16:17:39 <evrardjp> ok let's move on
16:17:43 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1721912
16:17:44 <openstack> Launchpad bug 1721912 in openstack-ansible "delegate_facts does not work with container connection plugin" [Undecided,New]
16:18:32 <evrardjp> a fun one :(
16:18:50 <evrardjp> it looks pretty valid
16:18:55 <andymccr> ugh
16:19:01 <evrardjp> we should probably have a test for that
16:19:12 <andymccr> that'd be at least high - because that will cause some weird outcomes
16:19:21 <evrardjp> yup.
16:19:50 <evrardjp> logan-: or jmccrory, did one of you got the chance to work on those?
16:20:15 <evrardjp> we start to have too many "high" bugs :/
16:20:31 <evrardjp> ok let's continue
16:20:39 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1721878
16:20:40 <openstack> Launchpad bug 1721878 in openstack-ansible "os_magnum: Pike: missing default_docker_volume_type" [Undecided,New]
16:21:11 <evrardjp> I think Florian has a point
16:21:58 <evrardjp> but it also makes sense to wire things up
16:23:26 <odyssey4me> ja, it probably makes sense to wire up if we can
16:23:28 <andymccr> yeah
16:23:43 <odyssey4me> regardless of whether magnum should be fixed, we'll have to carry a workaround
16:24:16 <odyssey4me> I do think that magnum should handle the issue more gracefully though
16:24:20 <evrardjp> in the meantime, because we can workaround in user variables, I'd tend to mark it as medium
16:24:38 <odyssey4me> funny enough, handling missing deps gracefully is one of the 12FA principles :p
16:24:53 <odyssey4me> we can either wire it up, or add a reno with a known issue
16:25:27 <evrardjp> odyssey4me: that's true
16:25:37 <evrardjp> we still need work there
16:25:47 <evrardjp> either docs for magnum, or wire code
16:25:54 <evrardjp> medium, ok everyone?
16:26:05 <jmccrory> maybe docs, similar to horizon here https://github.com/openstack/openstack-ansible-os_cinder/blob/master/doc/source/configure-cinder.rst#openstack-dashboard-horizon-configuration-for-cinder
16:26:17 <odyssey4me> ja, an established workaround is available
16:26:28 <odyssey4me> good suggestion there jmccrory
16:28:18 <evrardjp> ok next
16:28:33 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1721554
16:28:34 <openstack> Launchpad bug 1721554 in openstack-ansible "os_ceilometer fails without swift installed" [Undecided,New]
16:28:46 <evrardjp> ceilometer...
16:29:08 <evrardjp> I am working on the role maturity FYI, but in the meantime...
16:29:58 <evrardjp> what should we do?
16:30:06 <odyssey4me> are we going ahead with pulling those out from master at least?
16:30:36 <odyssey4me> whatever happens, we're going to have to maintain up to pike anyway because we didn't pull it from pike
16:30:57 <odyssey4me> so I guess we may as well figure out how to make it work and fix it
16:31:39 <evrardjp> ...
16:31:44 <evrardjp> lovely
16:31:56 <odyssey4me> that bug will need confirmation, but it looks plausible
16:32:08 <odyssey4me> I'd mark it low, given that those roles are unmaintained
16:32:22 <odyssey4me> hmm, maybe medium actually because there's no workaround
16:32:34 <andymccr> well its a problem in that it doesnt work in pike im sure so we are basically going to say "we cant fix it cos tahts a feature, but we cant drop it"
16:32:48 <andymccr> seems sensible to still have a thing saying "this role isnt maintained properly since newton" or w/e the case may be
16:33:18 <odyssey4me> if we take that stance, then perhaps we should remove those roles from integration all the way back to newton and do a minor rev
16:33:24 <odyssey4me> with a reno obviously
16:33:43 <evrardjp> maybe not newton if it works in N?
16:33:49 <andymccr> well i just think its misleading to keep them in for the sake of it
16:33:56 <evrardjp> I agree there
16:33:59 <odyssey4me> maybe leave N
16:34:00 <andymccr> like they dont work, or nobody is using/maintaining them
16:34:06 <andymccr> i think N works
16:34:12 <evrardjp> I think it's bad to set wrong expectation
16:34:17 <evrardjp> expectations
16:34:17 <odyssey4me> but O onwards has been unmaintained
16:34:17 <andymccr> yeah ^
16:34:24 <evrardjp> ok
16:34:35 <odyssey4me> yup - we just need to move all the stuff out into the roles and have the 'extras' stuff like cloudkitty
16:34:37 <andymccr> we get a tonne of bug reports on those and its like "cool but we need your help to fix it"
16:35:18 <evrardjp> yeah if I got a cent every metering stack bug report, I'd be iphone X world right now.
16:35:33 <evrardjp> ok maybe a dollar instead.
16:35:36 <evrardjp> anyway.
16:35:40 <jmccrory> that is a strange task though. why do ceilometer hosts need a swift user?
16:35:45 <openstackgerrit> Manuel Buil proposed openstack/openstack-ansible-os_neutron master: Make sure iptables is installed  https://review.openstack.org/510935
16:35:55 <jmccrory> https://github.com/openstack/openstack-ansible-os_ceilometer/blob/master/tasks/ceilometer_pre_install.yml#L32-L40
16:36:19 <odyssey4me> jmccrory because of gnocchi
16:36:33 <odyssey4me> if gnocchi uses swift, then it needs a swift user
16:36:57 <jmccrory> hmm ok
16:37:29 <evrardjp> In the meantime, let's not mark it as confirmed, I marked it as medium
16:37:50 <evrardjp> if we continue with the role deprecation work, and validate it, I can send a mail to the ML asking for contributors
16:38:05 <evrardjp> if no one comes over at next community meeting, we are done and we can deprecate it
16:38:18 <evrardjp> let's move to some other bug, for andymccr's pleasure:
16:38:23 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1721356
16:38:24 <openstack> Launchpad bug 1721356 in openstack-ansible "nova-placement-api haproxy health check is broken" [Undecided,New]
16:38:27 <odyssey4me> we should have pulled it out in ocata :/
16:38:34 <andymccr> i thought i fixed this
16:39:22 <evrardjp> andymccr: https://github.com/openstack/openstack-ansible/blob/master/group_vars/haproxy_all/haproxy.yml#L179-L180 ?
16:39:43 <andymccr> well apparently i didnt
16:39:44 <evrardjp> in https://github.com/openstack/openstack-ansible/commit/c4105464e6e5c1f199e8e256ced17208e913935c ?
16:39:45 <andymccr> since it hasnt changed
16:40:07 <logan-> my bug is from ocata
16:40:10 <logan-> maybe it didn't get backported
16:40:11 <andymccr> ahh
16:40:16 <andymccr> so maybe we just need to backport that
16:40:18 <andymccr> although i think
16:40:20 <andymccr> in ocata we do it slightly diff
16:40:29 <andymccr> because in ocata we use nginx + uwsgi
16:40:35 <andymccr> in pike+ we use uwsgi direct
16:40:36 <logan-> right
16:40:39 <evrardjp> oh
16:40:42 <evrardjp> that's it
16:40:59 <logan-> so in ocata when uwsgi fails to start, nginx does the bad gateway response and haproxy leaves the endpoint up
16:41:07 <andymccr> logan-: ahh
16:41:17 <evrardjp> on top of that haproxy config is different in O
16:41:26 <andymccr> maybe we need an expect there?
16:41:36 <andymccr> rather status expectation on haproxy
16:41:41 <andymccr> and to fix whatever is causing uwsgi not to start
16:41:57 <logan-> the uwsgi failing to start was my fault, but it uncovered this :)
16:42:03 <evrardjp> couldn't this be changed too https://github.com/openstack/openstack-ansible/blob/stable/ocata/playbooks/vars/configs/haproxy_config.yml#L153 ?
16:42:04 <andymccr> logan-: ahh ok fair enough
16:42:45 <evrardjp> I'd agree with andymccr there, maybe expect not 5xx
16:42:50 <logan-> yeah
16:42:56 <logan-> makes sense to me
16:43:09 <andymccr> well
16:43:16 <andymccr> in ocata we could probably do an expect 20x or something
16:43:33 <andymccr> the reason its diff in pike+ is because removing nginx means it doesnt forward to like /placement - you just hit direct
16:43:37 <andymccr> and that causes some weirdness with responses
16:43:40 <evrardjp> I thought you had all the 4xx or 3xx not really an issue
16:43:53 <andymccr> 401 is because it doesnt find the endpoint directly, unless you request /placement
16:44:09 <andymccr> but if you are using nginx it forwards / --> /placement so it should exist and not give a 401
16:44:16 <evrardjp> fair enough
16:44:18 <andymccr> but could be wrong
16:44:26 <andymccr> although doing not 5xx would bea. good start point
16:44:32 <andymccr> since if its actually broken it will 5xx
16:44:38 <evrardjp> yeah
16:44:50 <evrardjp> ok let's mark this as confirmed and ... ?
16:44:57 <andymccr> medium
16:45:00 <evrardjp> k
16:45:02 <andymccr> its only a problem if things are broken already
16:45:08 <andymccr> and dont do a logan- and break placement service :P
16:45:11 <odyssey4me> agreed
16:45:12 <logan-> :P
16:45:17 <odyssey4me> haha
16:45:49 <evrardjp> haha
16:46:04 <evrardjp> anyway, let's figure things out for last week's bugs not handled...
16:46:07 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1719517
16:46:08 <openstack> Launchpad bug 1719517 in openstack-ansible "Ceilometer policy.json includes python unicode encoding" [Undecided,New]
16:46:12 <andymccr> lol
16:46:38 <evrardjp> ;)
16:46:43 <evrardjp> let's move on to
16:46:44 <andymccr> maybe this thing does work?
16:46:45 <andymccr> or at least
16:46:50 <andymccr> christian seems to be giving it a go at fixing it?
16:46:54 <evrardjp> yeah
16:46:59 <evrardjp> sure!
16:47:01 <andymccr> if we can convince somebody to manage it that'd be awesome
16:47:01 <evrardjp> :p
16:47:14 <andymccr> otherwise my response is the same as the previous ceilometer bug
16:47:16 <evrardjp> I will contact him directly
16:47:24 <evrardjp> on top of the rest
16:47:26 <odyssey4me> it appears so - except it got caught in the jenkins/zuul fight
16:47:39 <andymccr> yeah i mean
16:47:42 <andymccr> that patch got shot down :P
16:47:50 <odyssey4me> well, maybe he could help maintain the roles ;)
16:48:05 <evrardjp> ok I understand your stance :)
16:48:06 <andymccr> si si
16:48:11 <evrardjp> let's move on a different bug
16:48:15 <evrardjp> #link #link https://bugs.launchpad.net/openstack-ansible/+bug/1714597
16:48:16 <openstack> Launchpad bug 1714597 in openstack-ansible "multi OS repo-build needs to be more intuitive " [Undecided,New]
16:48:18 <evrardjp> darn
16:48:19 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1714597
16:48:54 <evrardjp> no one reproduced it?
16:48:59 <evrardjp> can we continue our way?
16:49:06 <odyssey4me> I think you may have fixed the actual bug there evrardjp - the ansible_local thing not being a string?
16:49:38 <odyssey4me> https://review.openstack.org/#/q/I63817bb3c58a2c44d3e948bdb81005dc2e734c21
16:49:55 <evrardjp> yeah I remember that, but I am not sure it's linked to the first part of the bug
16:50:25 <evrardjp> dict object has no attribute repo_build
16:50:45 <odyssey4me> so the bug itself is incorrect
16:50:46 <evrardjp> maybe
16:50:59 <evrardjp> I think we should close this one down then
16:51:07 <evrardjp> or mark it incomplete
16:51:08 <odyssey4me> the stuff does detect and do the right things, but there have been reports of issues and unfortunately I have no test environment to work with on this
16:51:25 <odyssey4me> I can assign to me to try and replicate with your patch included
16:51:53 <odyssey4me> I intend to put some time into working on repo things on Friday this week.
16:51:55 <evrardjp> ok I'll leave it as is
16:52:00 <evrardjp> oh great
16:52:15 <evrardjp> I just added your name into the assignee
16:52:18 <evrardjp> let's move on
16:52:28 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1708360
16:52:29 <openstack> Launchpad bug 1708360 in openstack-ansible "Openstack-Ansible Install Fails with OVS" [Undecided,New]
16:53:05 <evrardjp> so here I think what would be great (in accordance with what odyssey4me and andymccr already said to me)... to have an ovs scenario
16:53:12 <evrardjp> so question
16:53:22 <evrardjp> hwoarang: what's your status there? :D
16:53:29 <andymccr> i see what you did there
16:53:30 <odyssey4me> yeah, that'd be nice - scenario and example config along with the others
16:53:46 <evrardjp> andymccr: D
16:55:03 <hwoarang> evrardjp: i will have to ask
16:55:06 <evrardjp> ok
16:55:07 <evrardjp> thanks
16:55:09 <hwoarang> since i am not the one doing the work
16:55:23 <openstackgerrit> Merged openstack/openstack-ansible-apt_package_pinning master: Add OpenStack-Ansible metadata  https://review.openstack.org/510469
16:55:24 <evrardjp> do you know who handles that?
16:55:29 <openstackgerrit> Merged openstack/openstack-ansible-ceph_client master: Add OpenStack-Ansible metadata  https://review.openstack.org/510470
16:55:38 <evrardjp> oh we have precedent ^
16:55:44 <evrardjp> but that's for another topic
16:55:57 <evrardjp> I suggest we close the bug triage conversation for today
16:56:04 <andymccr> +2
16:56:08 <hwoarang> evrardjp: it's epalper
16:56:12 <evrardjp> we can continue the OVS conversation outside the meeting
16:56:17 <evrardjp> thanks everyone!
16:56:23 <evrardjp> #endmeeting