16:00:28 <evrardjp__> #startmeeting openstack_ansible_meeting
16:00:29 <openstack> Meeting started Tue Apr 24 16:00:28 2018 UTC and is due to finish in 60 minutes.  The chair is evrardjp__. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:32 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:46 <evrardjp__> #topic What happened since last meeting
16:00:54 <openstackgerrit> Paul Belanger proposed openstack/ansible-hardening stable/pike: Remove fedora-26 / debian-jessie from testing  https://review.openstack.org/564016
16:00:57 <evrardjp__> Congrats Luigi Toscano (tosky) for joining us as core on os_sahara
16:01:02 <evrardjp__> A new no_log passwords rule is now in application
16:01:07 <pabelanger> evrardjp__: and for stable/pike also^ thanks
16:01:11 <evrardjp__> odyssey4me and evrardjp discussed disabling the broken idempotence test, vs backporting master patches. See: https://review.openstack.org/#/c/563567/1
16:01:16 <tosky> o/
16:01:18 <evrardjp__> evrardjp proposed mnaser to join on the core team
16:01:54 <mnaser> o/
16:01:54 <evrardjp__> As usual, if you have any extra information or things you want to share with the community, please write it in the next meeting agenda
16:02:14 <d34dh0r53> o/
16:02:36 <Tahvok> o/
16:02:43 <ansmith> o/
16:03:06 <evrardjp__> I'd like to continue with the bug triage meeting in a few minutes, then we can go for open discussion, particularily with the broken idempotence test
16:03:08 <spotz> o/
16:03:35 <evrardjp__> in the meantime, you have the occasion to read the links above :)
16:04:15 <evrardjp__> #topic bug triage
16:04:33 <evrardjp__> let's roll!
16:04:41 <evrardjp__> our first bug of the day:
16:04:43 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1766636
16:04:44 <openstack> Launchpad bug 1766636 in openstack-ansible "No need to restart rabbitmq if there is no version upgrade" [Undecided,New]
16:04:52 <Tahvok> That's mine
16:05:12 <evrardjp__> I completely agree with you Tahvok
16:05:20 <evrardjp__> how can improve this though?
16:05:43 <Tahvok> I just want to add: We are investigating an issue we had a day ago of running ansible. We did a minor version upgrade, and after infrastructure run, our ha network (vrrp) starteed jumping from one controller node to the other
16:05:46 <evrardjp__> checking package in the repo?
16:06:05 <Tahvok> evrardjp__: but we already do check it
16:06:14 <Tahvok> https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/ocata/tasks/rabbitmq_upgrade_check.yml#L68
16:06:18 <Tahvok> Look at the tasks here
16:06:30 <Tahvok> I'm really not sure why the check was not added
16:07:28 <Tahvok> I think this could be fixed with a simple 'when' statement
16:07:51 <evrardjp__> Tahvok: https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/ocata/tasks/rabbitmq_upgrade_check.yml#L56-L66
16:08:00 <evrardjp__> I think it's a doc issue
16:08:22 <Tahvok> I don't think so. The task you highlighted makes sense
16:08:47 <Tahvok> You need to upgrade rabbit, and it means rabbit will be restarted
16:08:56 <Tahvok> So you need to set the rabbitmq_upgrade
16:09:27 <Tahvok> However, even if this flag is set, there is still no reason to include rabbitmq_upgrade_prep.yml if there is no version change to be done
16:09:48 <evrardjp__> I don't see it that way
16:09:57 <evrardjp__> you run it without upgrade by default
16:10:05 <evrardjp__> it works if it's the same version
16:10:16 <evrardjp__> if different version it fails
16:10:21 <Tahvok> According to the docs, no, I always add the flag
16:10:24 <evrardjp__> it means you need to pay attention
16:10:32 <evrardjp__> which is why I am saying it's a docs issue.
16:10:56 <evrardjp__> but that could be problematic if we want full automatic
16:11:24 <Tahvok> I'm for automation here, which is why I think checking the version in the include task is all that's needed
16:11:43 <evrardjp__> but automation is synonym of downtime here
16:11:53 <Tahvok> That's correct
16:12:21 <Tahvok> But for that we could explain in the doc, that you should include the flag only when needed
16:12:22 <evrardjp__> I mean currently (due to docs), and in the future(if we change it)
16:12:44 <evrardjp__> I have no strong opinion
16:13:09 <evrardjp__> I will welcome a patch changing rabbitmq role or the documentation.
16:13:27 <evrardjp__> so I'd like to mark this as confirmed and, because it brings downtime, high.
16:14:39 <Tahvok> Ok, I can try working on a patch for it
16:16:02 <openstackgerrit> Merged openstack/ansible-hardening stable/queens: Remove fedora-26 / debian-jessie from testing  https://review.openstack.org/563682
16:16:14 <evrardjp__> Tahvok: yes I'd be fine with that
16:16:30 <evrardjp__> I am not 100% sure what you meant with the approach, so let's see
16:17:31 <Tahvok> Np, I'll open a review
16:17:33 <evrardjp__> ok let's move on
16:17:36 <evrardjp__> thanks Tahvok !
16:17:40 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1765438
16:17:41 <openstack> Launchpad bug 1765438 in openstack-ansible "RabbitMQ policy application not working for AIO" [Undecided,New]
16:17:46 <odyssey4me> thanks Tahvok
16:17:47 <Tahvok> Need to go now, thanks a lot for looking into it first!
16:18:09 <evrardjp__> yw!
16:18:33 <odyssey4me> yeah, that's me - I found the issue (stale facts for containers), and realised why it's not touching the gate too...
16:18:57 <odyssey4me> I'm toying with the idea of changing how we gather facts because, as it turns out - smart fact gathering it not very smart
16:19:05 <odyssey4me> *is
16:19:26 <odyssey4me> when used from gather_facts: in the playbook, it behaves differently to when you gather using the setup module in a task
16:19:34 <evrardjp__> :)
16:19:42 <evrardjp__> what do you mean by ansible ... not very smart?
16:19:44 <evrardjp__> :p
16:19:45 <odyssey4me> the first just checks if there are any facts, then moves on - the second actually verifies facts
16:20:05 <evrardjp__> I propose we mark this as confirmed and medium
16:20:11 <evrardjp__> it doesn't seem to hit the gates
16:20:19 <evrardjp__> and workarounds exist
16:20:26 <evrardjp__> anyone okay with that?
16:20:33 <odyssey4me> so anyway, in the gate we force fact gathering at specific times - I figyre that perhaps we should do more scoped fact gathering and also make it uniform between the gate and a normal playbook run.
16:20:44 <odyssey4me> ja, fine with that for me
16:21:06 <odyssey4me> mnaser I'll revert the revert once I've confirmed that it works right :)
16:21:12 <evrardjp__> I am all in with being more explicit
16:21:30 <evrardjp__> ok next
16:21:32 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1765432
16:21:33 <openstack> Launchpad bug 1765432 in openstack-ansible "Decide the source of the base images" [Undecided,New] - Assigned to Jesse Pretorius (jesse-pretorius)
16:21:53 <odyssey4me> ah yes - we had a hiccup with the opensuse image disappearing
16:22:01 <odyssey4me> thanks to hwoarang for putting in a quick workaround
16:22:13 <evrardjp__> thanks hwoarang !
16:22:17 <odyssey4me> I've suggested using diskimage-builder, and have done some testing and it seems a viable option.
16:22:23 <evrardjp__> hwoarang: for president!
16:22:41 <evrardjp__> it seems nice, but a new moving part.
16:22:46 <odyssey4me> I should have a test patch up some time soon when I get a little time to make it less of a hack.
16:23:07 <evrardjp__> I'd like to know if we have more or less moving parts with that. I'd say naturally less, but code speak for itself
16:23:20 <odyssey4me> at least it'll be a moving part we control and that behaves consistently - rather than some random image from the internet where the URL keeps changing.
16:24:12 <odyssey4me> I figure we can have two options - download from a URL, or build.
16:24:21 <odyssey4me> Then we default to building as it's the most reliable.
16:24:29 <evrardjp__> I like the idea to build, because it makes the offline story easier
16:24:38 <evrardjp__> more of it, if it doesn't fetch things from outside.
16:24:48 <odyssey4me> People can then do their own CI to build them centrally and set their deployments to download them if they like.
16:25:07 <evrardjp__> yes I am fine with that convention
16:25:44 <evrardjp__> I'd prefer if other people step in on the bug or with code. Code wins!
16:25:57 <evrardjp__> thanks for the first analysis odyssey4me
16:26:17 <evrardjp__> marking this as confirmed and low, there is no urgent fix required.
16:26:35 <evrardjp__> it could be only wishlist, but I think it's more important than that.
16:26:59 <evrardjp__> ok for everyone?
16:27:17 <evrardjp__> ok next
16:27:31 <evrardjp__> the rest are pending bugs:
16:27:33 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1758144
16:27:34 <openstack> Launchpad bug 1758144 in openstack-ansible "resolv.conf in containers set too late" [Undecided,New] - Assigned to Logan V (loganv)
16:27:40 <evrardjp__> logan-: are you there?
16:28:09 <evrardjp__> I am unassigning this, so other ppl might have a stab at this. Anyone wanting to help there?
16:28:33 <evrardjp__> prutty pliiiiz?
16:28:55 <evrardjp__> I meant "I'd welcome help there"
16:28:58 <evrardjp__> ok next
16:29:02 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1755821
16:29:03 <openstack> Launchpad bug 1755821 in openstack-ansible "config_template fails to parse template if it contains a comment with leading spaces" [High,New] - Assigned to Kevin Carter (kevin-carter)
16:29:16 <evrardjp__> cloudnull: did you get the chance to look at it?
16:29:34 <evrardjp__> same thing then.
16:29:43 <evrardjp__> next
16:29:45 <evrardjp__> #link https://bugs.launchpad.net/openstack-ansible/+bug/1743032
16:29:47 <openstack> Launchpad bug 1743032 in openstack-ansible "Galera cluster maintenance in OpenStack-Ansible" [Undecided,New] - Assigned to Kevin Carter (kevin-carter)
16:29:58 <evrardjp__> same thing.
16:30:10 <evrardjp__> ok we're done for triage
16:30:14 <evrardjp__> #topic open discussion
16:30:40 <evrardjp__> weirdly I see very few bugs this week. I am worried.
16:30:54 <evrardjp__> Are people stopping using our software, or are we very reliable suddenly?
16:30:56 <evrardjp__> :p
16:31:27 <tosky> it's spring time maybe
16:31:42 <evrardjp__> weather was very good in europe last week.
16:31:50 <evrardjp__> everyone went outside instead of doing IT stuff.
16:31:52 <evrardjp__> :)
16:31:58 <evrardjp__> haha
16:32:00 <evrardjp__> ok
16:32:04 <evrardjp__> any other topic?
16:32:07 <odyssey4me> heh, fair enough
16:32:21 <evrardjp__> ok thanks for your time everyone
16:32:45 <evrardjp__> #endmeeting