16:29:05 #startmeeting openstack_ansible_meeting 16:29:06 Meeting started Tue May 29 16:29:05 2018 UTC and is due to finish in 60 minutes. The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:29:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:29:09 The meeting name has been set to 'openstack_ansible_meeting' 16:29:19 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:29:32 #topic roll call 16:29:36 o/ 16:29:36 o/ 16:30:02 o/ 16:30:42 lets give folks a couple min to roll in, i was late on getting started. 16:30:57 johnsom ah, sorry - wrong ref - it's this one: https://review.openstack.org/570914 16:32:01 o/ 16:32:08 Lets get started. 16:32:09 #topic Topics for Discussion 16:32:15 #link https://etherpad.openstack.org/p/YVR-openstack-ansible 16:32:33 ^ Summit discussion from last week 16:32:51 as most should know, the summit was last week so I'm sure many of us are still recovering from that :) 16:32:57 o/ 16:33:05 o/ 16:33:11 topics will be a little light given the fact taht many of us were away 16:33:27 did we get anything out of the forum sessions etc? 16:34:06 in the previous meeting we talked about the PTG, if folks can continue to add to the PTG planning etherpad it'd be great to keep momentum there 16:34:07 #link https://etherpad.openstack.org/p/osa-denver-PTG-planning 16:34:27 before we dive into bugs lets have a round of open discussion. 16:34:28 thats last denvrs :D 16:34:34 we'll need a denver2-PTG-planning :) 16:34:49 denver 2.0 16:35:00 Denver PTG 2 - too train, too choo. 16:35:09 ops, fair enough, I'll make a new etherpad. 16:35:24 Merged openstack/openstack-ansible-os_rally stable/ocata: Pin cmd2 to the last python2 version of the library https://review.openstack.org/570930 16:35:43 andymccr the forum discussions were good, we heard back from a few users. I think there are a acouple things we can do to help make onboarding better. 16:36:00 excellent! 16:36:12 also there seems to be a lot of interest in documenting a brownfield deployment process 16:36:18 mnaser ^ 16:36:27 something we talked about a the feedback session 16:36:34 thats pretty consistent feedback too 16:37:33 we also talked to a couple users wanting a zun role for deployment. 16:37:40 we worked on that while at the summit 16:37:58 #link https://github.com/os-cloud/os_zun 16:38:06 hopefully we can get that imported this cycle 16:38:17 anyone have anything they want to talk about ? 16:38:25 #topic open discussion 16:39:40 Denver PTG 2.0 link 16:39:43 #link https://etherpad.openstack.org/p/osa-denver-PTG-planning-2.0 16:39:44 haha 16:39:46 nice 16:40:02 i had very good results with the ELK stack from the ops repo, would encourage anyone else interested to give it a try 16:40:09 ++ 16:40:25 it's pretty functional with queens too 16:40:38 d34dh0r53 and I were talking at the summit and discovered that most services have a profiler section 16:40:53 and we should be able to publish notifications naively into ELK 16:40:54 yes, osprofiler looks interesting 16:41:12 (on the topic of ELK, i'm curious if anyone has connected Graylog to OSA-deployed OpenStack) 16:41:13 which fits nicely into the new ELK stack 16:41:14 https://docs.openstack.org/osprofiler/latest/ 16:41:17 oh very nice :) 16:41:42 cmart I think evrardjp has done something, although he's not pushed it up as a user story yet 16:42:05 example profiler config in OS services https://github.com/os-cloud/os_zun/blob/master/templates/zun.conf.j2#L2054-L2164 16:42:05 cmart: yes we have graylog consuming rsyslog from OSA but tbh i'm preferring the elk stuff 16:42:29 cool. jrosser curious why, but we can take that out of band 16:42:37 sure, np 16:42:49 this is a perfectly good time to chat about that if you want :) 16:43:03 next topic is bug triage 16:43:14 so we can talk about ops things for a min more or we can move right in to taht 16:43:16 **that 16:43:22 ok then. jrosser why do you prefer ELK to Graylog? 16:43:41 it was purely that people were more familiar wth Kibana than Graylog, nothing more than that 16:44:02 could get going immediatley rather than learning something new 16:44:38 but it seems very much a matter of personal taste 16:45:14 yeah. IIRC Graylog now uses Elasticsearch under the hood, so the main difference would be the sorting/filtering UI 16:47:40 within the recent releases of greeylog it doesn't loook like it works with ELK6 16:47:46 yet 16:47:56 it'd be good to perhaps transition the elk ops playbooks to use a good elasticsearch role than can be commonly used across both implementations, and that supports building a cluster properly 16:48:26 the ELK things that we've been using are all ELK 6 at this time 16:48:37 i did see there was a blueprint for ELK in OSA? 16:48:45 odyssey4me: it] 16:48:49 bah... 16:49:11 odyssey4me it'd be great if there was such a role. the one from Elastic seems neglected. 16:49:27 however the playbooks in the ops repo does do clustering 16:49:32 ja, I found a few that looked reasonable - but didn't spend enough time evaluating them properly 16:49:58 if there really isn't a good one, then perhaps we could curate one 16:50:07 I have a 5 node cluster humming along, I think jrosser has something similar 16:50:16 very cool :) 16:50:34 I do think it'd be great get some user stories published around these tools in the ops repo 16:50:47 its a bit tribal knowledge at this time 16:50:49 yes, i just rolled the ops repo stuff straight out 16:51:15 i have some pending reviews to make it better in queens, it's very journal oriented atm 16:51:57 #action cloudnull to review the open prs to the ELK bits in the ops repo 16:52:25 anything else we want to talk about regarding the ops things? 16:52:45 any other topics of conversation we want to tackle right now 16:52:51 Yeah, the ELK spec is basically being handled in the ops repo at this point, although I think we should consider moving it out given the nature of the ops repo :) 16:53:07 Or do some more thorough reviews of commits to the ops repo 16:53:50 well, actually we'll discuss this at the PTG, but I think we should not move anything into the integrated repo unless it's openstack and we should use user-stories and the ops repo for non-openstack things 16:53:51 we cloud host the ELK things outside of the openstack namespace, or potentially setup a selective CI within ops repo to better test some of the components ? 16:54:22 otherwise the integrated repo just get jammed with more and more things which really have very little to do with the deployment of openstack 16:54:27 Yes odyssey4me I totally agree, perhaps more CI in ops is the answer 16:54:54 CI + documentation :) 16:55:18 ok lets move on to cover some of these open bugs 16:55:42 yep, seems better to me - a basic high level view in user stories with a referral to the ops repo which contains stuff useful for multiple series 16:55:57 #topic Bug Triage 16:56:01 #link https://bugs.launchpad.net/openstack-ansible 16:56:29 first up https://bugs.launchpad.net/openstack-ansible/+bug/1773925 16:56:30 Launchpad bug 1773925 in openstack-ansible "ceph_client: client commands should be executed by non-root user" [Undecided,New] 16:57:13 looks like we need to do some work in the ceph client role to remove root assumptions 16:57:49 well, that's true for all our playbooks actually 16:58:03 I'm thinking wishlist 16:58:22 given the fact we know root is documented as a requirement at this point. 17:00:40 ok nextr 17:00:41 https://bugs.launchpad.net/openstack-ansible/+bug/1773854 17:00:42 Launchpad bug 1773854 in openstack-ansible "Package rdo-release-queens is not signed" [Undecided,New] 17:01:10 I think there was some chatter in the channel for this today ? 17:01:17 something we know about ? 17:02:45 mnaser ^ ? 17:03:20 I'm inclined to mark this incomplete, but i really don't know given that I dont do much with cent 17:04:15 #link http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/latest.log.html#t2018-05-29T08:32:23 17:04:21 maybe related? 17:04:25 odyssey4me >? 17:05:34 sorry, had to go to the door then the dog ran out :p 17:07:02 I have no idea - not much info provided there - no branch/tag/whatever 17:07:15 yea, asked for more details. 17:07:30 moving on https://bugs.launchpad.net/openstack-ansible/+bug/1773793 17:07:30 Launchpad bug 1773793 in openstack-ansible "User Guide in OpenStack-Ansible has wrong IP address for haproxy_keepalived_internal_vip_cidr " [Undecided,New] 17:08:35 I don't really know whether that's right or not, personally. I don't know much about how that all works. 17:09:02 The var says it's a CIDR, so it seems to me the docs are right? 17:09:06 I think the examples are being interpreted as literals 17:09:24 we might need to add some words around that. 17:09:37 looks like there's a patch provided in the bug text 17:10:08 if it works and makes people understand better, then LGTM and seems like a low-hanging-fruit thing 17:10:25 ++ 17:10:38 the docs source those example files, but obviously the bug reporter doesn't know that :p 17:11:08 ++ confirmed and tagged 17:11:30 next https://bugs.launchpad.net/openstack-ansible/+bug/1772778 17:11:31 Launchpad bug 1772778 in openstack-ansible "skipping: no hosts matched" [Undecided,New] 17:12:00 Maksim Malchuk proposed openstack/openstack-ansible-os_tempest master: Pin cmd2 to the last python2 version of the library https://review.openstack.org/570960 17:12:10 I assume this is something to do with the openstack_user_config 17:12:31 if it works with a couple hosts then it stands to reason that its generally "working" 17:13:42 will --limit to the host hit any of the containers at all? 17:14:08 it won't, and that's the issue here 17:14:23 I helped this guy out on friday I think 17:14:27 lemme find the eavesdrop 17:14:39 I think that’s an infra issue 17:14:51 Regarding the rdo stuff 17:15:07 mnaser orly 17:15:18 something in the infra mirrors ? 17:16:28 No maybe like user déployer error cloudnull 17:17:02 are we still talking about 1772778? 17:17:02 oh, that makes a lot of sense 17:19:59 yes 17:20:27 marked incomplete and moving on :) 17:20:27 I think it's invalid 17:20:35 incomplete is fine for now 17:21:05 https://bugs.launchpad.net/openstack-ansible/+bug/1706301 17:21:07 Launchpad bug 1706301 in openstack-ansible "nova-spicehtml5proxy.service is missing exec reload and task fail" [Undecided,Incomplete] - Assigned to Major Hayden (rackerhacker) 17:21:09 Merged openstack/openstack-ansible-tests stable/pike: Use upper constraints when installing ARA https://review.openstack.org/570909 17:21:09 Merged openstack/openstack-ansible-tests stable/queens: Use upper constraints when installing ARA https://review.openstack.org/570907 17:21:10 ok, for 1772778 there's a bunch of discussion between tux__ , myself and jrosser in http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2018-05-23.log.html 17:21:25 cool 17:21:27 perhaps a ref to that is best added to the bug for context 17:21:30 will add that the bug 17:21:46 last one for the day is 1706301 17:22:31 oh, when I tested a bunch of that some time ago - the vnc/spice proxies did not support reload 17:23:16 ok 17:23:16 oh the real bug is further below - when you switch from one to the other, the old thing stays behind 17:23:18 I still think we should change it to run them all, and just have one as primary 17:23:43 * odyssey4me adds that to my TODO for rage patching :p 17:23:57 I think this has been resolved https://bugs.launchpad.net/openstack-ansible/+bug/1772778 17:23:58 Launchpad bug 1772778 in openstack-ansible "skipping: no hosts matched" [Undecided,Incomplete] 17:23:59 but yes, it'd be nice for us to do clean-up if it's switched 17:24:02 I still don't know how can it be done, but okay, I trust you won't break everything :) 17:24:34 odyssey4me ++ I have to agree that having the consoles just be generally available would be ideal 17:24:56 * cloudnull assigns bug to odyssey4me 17:25:01 :) 17:25:58 ok thats enough bugs for the day 17:26:04 evrardjp they all listen on different ports, so they can easily all run together 17:26:09 #topic open discussion 17:26:10 cloudnull: and the other bugs? 17:26:13 anything else we ant to talk about 17:26:28 https://bugs.launchpad.net/openstack-ansible/+bugs?search=Search&field.status=New 17:26:37 evrardjp they're there, we're kinda running short on time 17:26:42 k 17:27:43 ok, welp, with that, thanks everyone! 17:27:57 Have a great rest of your day 17:28:00 #endmeeting