16:01:47 #startmeeting openstack_ansible_meeting 16:01:47 Meeting started Tue Apr 11 16:01:47 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:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:50 The meeting name has been set to 'openstack_ansible_meeting' 16:01:59 woo bug triage :D 16:02:10 * lbragstad lingers 16:02:10 \o/ 16:02:15 lbragstad: it's too fun to leave 16:02:31 much fun #amaze 16:02:41 lbragstad: just wait until evrardjp and andymccr get started 16:02:43 It's a rollercoaster 16:02:44 lbragstad: we don't have any opinionated things i think - we would carry an empty template that can be "template config'd) 16:02:55 andymccr ++ 16:02:59 * lbragstad grabs some popcorn 16:03:11 #topic Review of last week action points 16:03:16 well. 16:03:24 I'm sad to say I didn't do my work properly 16:03:33 #action evrardjp review https://bugs.launchpad.net/openstack-ansible/+bug/1678165 16:03:34 Launchpad bug 1678165 in openstack-ansible "dynamic_inventory.py container_mtu bug" [Undecided,New] 16:03:36 you should've been here in the beginning weeks of the cycle because that was a rollercoaster - but now its manageable :P 16:03:55 No other action points 16:04:08 #topic this week triage \o/ 16:04:24 so our first for today is: 16:04:26 #link https://bugs.launchpad.net/openstack-ansible/+bug/1681742 16:04:27 Launchpad bug 1681742 in openstack-ansible "Securing services with SSL certificates link broken" [Undecided,In progress] - Assigned to Chason (chen-xing) 16:04:57 that was easy. 16:05:13 we just have to review what was done 3 minutes ago! 16:05:24 next 16:05:27 #link https://bugs.launchpad.net/openstack-ansible/+bug/1681714 16:05:28 Launchpad bug 1681714 in openstack-ansible " Ceph cluster’s performance are not monitored by Telegraf" [Undecided,New] - Assigned to Bertrand Lallau (bertrand-lallau) 16:05:42 confirmed wishlist ? 16:05:55 yeah 16:05:56 agreed 16:05:57 yeah 16:06:04 next 16:06:04 also looks like Bertrand is taking care of it which is awesome :) 16:06:05 #link https://bugs.launchpad.net/openstack-ansible/+bug/1681695 16:06:06 Launchpad bug 1681695 in openstack-ansible "Incorrect keystone with multiple memcache configuration" [Undecided,New] - Assigned to Jean-Philippe Evrard (jean-philippe-evrard) 16:06:22 what??? I was assigned this? 16:06:38 k 16:06:40 hehehe, enjoy?:) 16:06:46 let's see how this one goes. 16:07:01 evrardjp: its cos you wrote a patch :) 16:07:02 I'm not sure if my fix gonna fix everything, so let's see with expert keystone advice 16:07:06 so far so good on bug triage! 16:07:10 yeah. 16:07:14 but it's related 16:07:17 not fixed 16:07:23 damnit! fix it properly :P 16:07:27 haha 16:07:59 let's move on we'll see later if that needs a change of status 16:08:13 next 16:08:13 #link https://bugs.launchpad.net/openstack-ansible/+bug/1681372 16:08:14 Launchpad bug 1681372 in openstack-ansible "Having a pre installed Ansible in a different location causes AIO issues." [Undecided,New] 16:08:46 ahh yeah this is kinda interesting 16:09:15 agreed. 16:09:20 medium or high? 16:09:23 I think we should let ppl use their own ansible 16:09:30 agreed 16:09:35 although im wondering if we shouldn't deploy our ansible in a venv? 16:09:35 I'd be enclined to make it medium at minimum 16:09:37 we create a binary anyway? 16:09:47 chen.xing proposed openstack/openstack-ansible-os_keystone master: Fix the dead link https://review.openstack.org/455766 16:10:15 well the question is do we need to andymccr? 16:10:36 we could leave the responsibility to the deployer if he doesn't want to use bootstrap_ansible 16:10:39 evrardjp: well that way we can allow you to use whatever versions of whatever you want. 16:10:49 agreed - but perhaps if you want to use the bootstrap (and know it'll work) we can support it in a venv 16:11:25 i think hughsaunders came across a slightly similar but unrelated issue around the versioning of pip packages we install which also wouldn't have happened if we used a venv 16:11:30 oh you mean adding a new feature of "bring your own ansible" and we just link to it, as we do now? 16:11:47 haven't we tried ansible in venv and found it didn't behave nicely? 16:11:51 and then continue as we do (the roles etc) 16:12:00 stevelle: I think it's in a venv now :p 16:12:07 stevelle: not sure - im mostly just theorizing. 16:12:13 evrardjp: i dont think it is in integrated build 16:12:16 ok 16:12:24 in role builds it is though since tox runs environments :P 16:12:54 I thought it was in /opt/ansible-runtine 16:12:57 runtime* 16:13:12 anyway 16:13:15 The question is 16:13:20 the key issue, imo, is that you (as a deployer) could have any sort of tools that have package version issues with our deploy - and since its not in a venv that would cause problems 16:13:25 how do we prioritize this 16:13:34 hmm 16:13:49 is that a new feature we want, or do we think we should always have this 16:13:49 cloudnull: ^ thoughts if you're about? 16:14:24 IMO it's a bug, and everyone should be able to use its own ansible. But not using bootstrap_ansible then. So the bug only becomes a docs bug. 16:14:34 Which changes the impact. 16:14:41 Which means me! 16:14:54 :) 16:15:11 And clear comments on the bug as to what we need to fix:) 16:15:18 evrardjp: hmm - i guess you could say it that way. an alternative fix is to only link the binaries we know exist, e.g. which ansible-playbook and then link from inside that dir rather than the ansible-runtime/bin 16:15:44 yes, in the script we have a || ansible-playbook we could maybe remove 16:16:00 so confirmed medium + docs? 16:16:07 evrardjp: yeah lets say that 16:16:31 why can't they use bootstrap_ansible though 16:16:39 chen.xing proposed openstack/openstack-ansible master: Fix the dead link https://review.openstack.org/455771 16:16:45 our wrapper turns out to be pretty helpful 16:17:15 stevelle: IMO if the deployer wants to have its own ansible, we should consider (s)he skips the ansible building 16:17:29 the deployer should be smart enough to install roles, and load variables. 16:17:53 that breaks every bit of doc we have, which assumes the wrapper 16:17:54 well that's my opinion :p 16:18:06 it's a high hurdle 16:18:32 it's just a question of documenting that if you're not using bootstrap ansible (and using your own), you can't use the wrapper and the nice tooling we've made 16:18:51 so can we not just rewrite that code to check where ansible-playbook binary exists and not just link with an assumption 16:19:12 but I already see issues coming with older ansible versions that are breaking things because we just "re-use" the old ansible binary 16:19:17 i still quite like the idea of having it in a venv since it means we can have our own requirements and the deployer can use whatever requirements/packages they want outisde of that binary - but im not sure how possible that is :) 16:19:18 binaries* 16:19:37 I don't think that will be that hard 16:19:39 evrardjp: i think thats the benefit of the bootstrap process - we can ensure you are using a tested/up to date version that works with our plays 16:19:44 maybe we should build a test there 16:19:46 haha. 16:19:46 yeah 16:19:50 good thought ;) 16:20:04 chen.xing proposed openstack/openstack-ansible master: Fix the dead link https://review.openstack.org/455771 16:20:06 stevelle may be right though around the ansible version stuff 16:20:15 there is probably something in the meta that could be used if you see what I mean :D 16:20:59 we can add an ansible version check to the bootstrap, for existing packages pretty easily 16:21:21 Amy Marrich (spotz) proposed openstack/openstack-ansible master: [DOCS] Fix the dead link https://review.openstack.org/455771 16:21:53 I think we all agree there 16:22:02 let's continue then! 16:22:04 #link https://bugs.launchpad.net/openstack-ansible/+bug/1680948 16:22:05 Launchpad bug 1680948 in openstack-ansible "cannot see status of mysql cluster with -h localhost on centos" [Undecided,New] 16:22:31 im sure this is a centos issue - we had problems when we first added centos support because localhost didnt work on mysql where 127.0.0.1 did 16:22:47 probably a my.cnf change? 16:22:50 I don't know 16:23:15 mgariepy: are you there? 16:24:02 i think -h 127.0.0.1 works 16:24:23 Is this someone you did directly (inspired by our docs), or just because you needed it? In the former could you point to docs, in the latter did you try 127.0.0.1 ? 16:24:42 let's continue before confirming the source of the issue 16:24:55 ok cool 16:24:57 let's continue* 16:25:06 we'll see when he'll be back :) 16:25:11 next 16:25:14 #link https://bugs.launchpad.net/openstack-ansible/+bug/1680233 16:25:15 Launchpad bug 1680233 in openstack-ansible "re-running os-glance with NFS mount breaks" [Undecided,New] 16:25:39 i put a comment in there 16:25:47 (the centos mysql one) 16:26:02 Amy Marrich (spotz) proposed openstack/openstack-ansible-os_horizon master: [DOCS] Fix the dead link https://review.openstack.org/455763 16:26:14 andymccr: thanks. 16:27:15 that sounds real and i'd say high 16:28:00 Agreed. 16:28:19 do you have cycles for it? 16:28:32 evrardjp: yeah i'll take it 16:28:39 cool thanks 16:28:44 next 16:28:45 #link https://bugs.launchpad.net/openstack-ansible/+bug/1680075 16:28:47 Launchpad bug 1680075 in openstack-ansible "keystone fails with haproxy in maint mode" [Undecided,New] 16:29:02 logan-: ? 16:29:17 looking 16:29:26 it could be useful for you I think :) 16:30:10 oh you know what 16:30:12 I need to wrap up https://review.openstack.org/#/c/438224/ 16:30:16 ill do that asa 16:30:18 asap* 16:30:41 haha great! 16:30:48 don't forget to tag the bug there :) 16:30:52 yep will do 16:30:56 can you assign the bug to me please 16:30:58 thanks! 16:31:00 sure 16:31:47 last one was the one of last week 16:31:50 #link https://bugs.launchpad.net/openstack-ansible/+bug/1678165 16:31:51 Launchpad bug 1678165 in openstack-ansible "dynamic_inventory.py container_mtu bug" [Undecided,New] 16:31:57 I didn't got the chance to triage this 16:32:14 hmm 16:32:15 did someone got the chance to do it? 16:32:30 I added it again to my action points for next week. 16:32:56 I think Nolan is on holiday 16:33:07 cloudnull: opinion ? 16:33:29 confirmed 16:33:42 k 16:33:53 if that option is set when the inventory is first created it works 16:34:00 otherwise it does not 16:34:10 and requires the deployer to go in and manually set it 16:34:17 I worked with BjoernT on that 16:34:20 ok 16:34:31 importance? 16:34:38 Is there a fix somewhere? 16:34:57 Andy McCrae proposed openstack/openstack-ansible-os_glance master: Default to "omit" mode from directory creation https://review.openstack.org/455776 16:35:00 probably prio2 16:35:05 (or in the work) 16:35:18 BjoernT: haha :) 16:35:23 lol 16:35:39 yeah I was wondering what else is broken... 16:35:41 it sounds serious because of expactations 16:35:43 -a 16:35:50 yeah 16:36:14 andymccr, i'll take care of https://bugs.launchpad.net/openstack-ansible/+bug/1680948 when I have 2 minutes. 16:36:16 Launchpad bug 1680948 in openstack-ansible "cannot see status of mysql cluster with -h localhost on centos" [Undecided,New] - Assigned to Marc Gariépy (mgariepy) 16:36:22 I'd rather say high 16:36:23 ok cool thanks mgariepy :) 16:36:31 thanks mgariepy! 16:36:36 small doc update :) 16:36:45 ahah I knew it! :p 16:36:56 anyway, for the last bug? 16:36:57 ooh ohh docs to me!!!! 16:37:09 Has someone cycles to work on this? 16:37:16 That's gonna be a fun one and important ones 16:37:36 cloudnull: you are already familiar with it? 16:37:59 s/ones/one/ 16:37:59 on what ? 16:38:04 on https://bugs.launchpad.net/openstack-ansible/+bug/1678165 16:38:05 Launchpad bug 1678165 in openstack-ansible "dynamic_inventory.py container_mtu bug" [High,Confirmed] 16:38:20 after that we can close the bug triage 16:38:24 for today 16:38:56 Ok I'll stop pushing :) 16:39:13 That's all for today 16:39:15 Thanks everyone! 16:39:19 #endmeeting