16:01:24 <andymccr> #startmeeting openstack_ansible_meeting
16:01:25 <openstack> Meeting started Thu May 18 16:01:24 2017 UTC and is due to finish in 60 minutes.  The chair is andymccr. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:29 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:29 <andymccr> #topic rollcall
16:01:35 <andymccr> o/
16:01:36 <d34dh0r53> o/
16:01:39 * mhayden wheeeeees
16:01:41 <andymccr> haha
16:01:47 <logan-> \o
16:01:51 * mhayden wheezes for d34dh0r53
16:02:21 <d34dh0r53> whiz bang?
16:03:04 <andymccr> give it a few more mins!
16:04:23 <palendae> o/
16:04:43 <evrardjp> 0/
16:05:31 <andymccr> ok lets get this ball rollin then!
16:05:46 <andymccr> #topic review action items from last last week
16:05:52 <andymccr> add spec for hyper-converge - mhayden cloudnull
16:07:01 * mhayden looks around and whistles
16:07:03 <andymccr> mhayden: since you're here - i saw this work actually merged already. im kinda wanting to revert that - for 2 reasons: 1. we dont have an upgrade path for that atm, and 2. there are some concerns around running some services in the same containers - nova-conductor (db access) on the same container as nova-api (no db access) as an example.
16:07:16 <andymccr> it would definitely be better to have a spec to start that one off
16:07:25 <andymccr> or at a minimum having an upgrade path that is considered and works
16:07:33 <mhayden> i agree with that
16:07:47 <mhayden> i'm testing hyperconverged in prod in my OSA cloud ;)
16:08:23 <andymccr> so the options im proposing to you & cloudnull - 1. revert that patch and then you can do the spec + work + upgrade path, or 2. add the upgrade path in before release time
16:08:44 <andymccr> im trying to avoid running around like a headless chicken near release time when upgrades are not functioning :P
16:09:25 <andymccr> mhayden: want to pick an option? :P
16:09:34 <andymccr> fwiw i really like the idea - i think its a great move.
16:09:40 <andymccr> but it has to work for ugprades etc
16:09:48 <evrardjp> agreed
16:10:01 <andymccr> another alternative would be to have set of the env.d files available to use if you want to - for new deploys or as an option of different architectures
16:10:48 <mhayden> hmm
16:10:49 <evrardjp> that could be just a doc change
16:11:11 <mhayden> andymccr: i guess we can revert it and figure out a good way to do it going forward
16:11:22 <mhayden> not sure i have the cycles to devote to the upgrade work
16:11:34 <andymccr> mhayden: ok i will handle the revert
16:11:43 <andymccr> but i think i'll move the current options out of the way into a directory that isnt used by default
16:11:48 <andymccr> because i think the work is useful
16:12:20 <andymccr> ok moving along!
16:12:30 <andymccr> prod on the py35 requirements goal
16:12:44 <andymccr> so - im guessing nobody is able to take this one on - i'm going to start looking at it, once i progress the uwsgi/nginx bits
16:13:02 <andymccr> so tl;dr i';ll take that unless there is somebody else who wants to give it a go ;P
16:13:21 <andymccr> #action andymccr revert hyperconverge patch
16:13:33 <andymccr> #topic Boston Summit Recap
16:13:57 <andymccr> SO! Boston was really successful I believe - I have a blog writeup for that if anybody is interested
16:14:10 <andymccr> #link http://blog.andy.mc.it/osa-boston-recap/
16:14:24 <andymccr> including links to some talks etc. so take a look if you're interested!
16:15:28 <andymccr> #topic PTG 11-15 September - Denver, Colorado
16:15:46 <evrardjp> thanks for the blog post
16:15:47 <andymccr> So another reminder for everybody to start planning that one, its quite a way off now, but it'll be here sooner than you realise :P
16:16:04 <andymccr> #action everybody to start investigating options for the PTG 11-15 September in Denver
16:16:50 <andymccr> #topic Release planning and decisions
16:17:56 <evrardjp> decisions?
16:18:15 <andymccr> Pike Milestone 2 is coming up in the week of 5-9 June, which signals the membership freeze for Pike meaning new roles cant be part of a release after that point
16:18:31 <andymccr> so if you have a role that you want released as part of Pike please make sure it's in by milestone2
16:18:53 <andymccr> evrardjp: could be discussions :P could change in the wiki
16:19:45 <evrardjp> details...
16:19:50 <andymccr> Other than that - Ocata 15.1.3 and Newton 14.2.3 releases went out on Monday, so we'll be releaseing 15.1.4 and 14.2.4 in 2 weeks
16:19:59 <andymccr> any changes that are needed, as always, let me know!
16:20:29 <andymccr> #topic Blueprint work
16:20:55 <andymccr> ok so the uwsgi/nginx bits - im updating that patch now that imback from the summit, and i'll be asking for more feedback personally from people who have shown interest
16:21:10 <andymccr> #link https://review.openstack.org/#/c/458595/
16:21:13 <andymccr> if you'd like to take a look!
16:21:47 <andymccr> but we need to be moving forward with this soon, so i'll be pressing more intently soon :)
16:21:52 <cloudnull> andymccr: I'll take on adding in the upgrade work
16:21:58 <cloudnull> that way you dont have to revert that pr
16:22:02 <andymccr> cloudnull: ok cool
16:22:04 * cloudnull sorry late to the party
16:22:31 <andymccr> cloudnull: sounds good. i know odyssey4me has some concerns around co-locating certain services, so there may still be some pushback but as long as all is good and happy by release im ok with that
16:23:09 * cloudnull sorry late to the party ++
16:23:13 <cloudnull> haa
16:23:19 <evrardjp> I'd prefer we rollback and provide the two in one commit then?
16:23:37 <cloudnull> ^ I'd perfer not that
16:23:39 <cloudnull> :)
16:23:47 <andymccr> i can make a revert that is essentially a "move out of the way" so the patch could just move it back in the way? happy medium? :P
16:23:48 <evrardjp> else if one doesn't make it we'll be split between two chairs.
16:24:08 <odyssey4me> I'd prefer to see a spec agreed to which includes what co-locates with what.
16:24:39 <andymccr> the actual change is reasonably easy - the upgrade bits are harder.
16:24:59 * d34dh0r53 registered an ELK blueprint, should we talk about that now or wait for open discussion?
16:25:00 <andymccr> the TL;DR from me is that it has to work at release, for upgrades - or else i will not be happy :)
16:25:03 <evrardjp> I guess we're good for the revert and the spec + implementation including upgrade?
16:25:08 <odyssey4me> and then the commit to do the change should include an upgrade fix to clean up anything left behind
16:25:35 <andymccr> d34dh0r53: yeah definitely, want me to add it to the agenda as a weekly thing?
16:25:51 <d34dh0r53> andymccr: sure
16:26:40 <andymccr> ok lets figure out the upgrade bits + spec/revert/whatever we want to do after this then
16:26:48 * andymccr hands d34dh0r53 the mic
16:26:54 <d34dh0r53> I'm 90% done with the role breakouts and upgrade to 5.x, really wondering where to land my work at this point.
16:27:11 <d34dh0r53> whether I should go for roles within OSA proper or put it in openstack-ansible-ops
16:27:39 <logan-> d34dh0r53: thats awesome to hear.
16:27:42 <evrardjp> I'd be enclined to put it under the openstack-ansible umbrella directly
16:27:57 <andymccr> evrardjp: you mean a new set of roles?
16:28:14 <evrardjp> yeah, why not, if they are respecting our standards?
16:28:20 <logan-> how does milestone 2 role freeze stuff affect that if there's no hosts in the ELK groups by default (ie opt in only)
16:29:08 <andymccr> logan-: the only real impact is that it wouldnt be included in the release of OSA. the repo will still exist and we can sitll branch it etc, but when OSA 16.0.1 goes out (for example) it won't include ELK sha's
16:29:51 <d34dh0r53> so it could live in ops for pike and become osa proper in Q
16:29:54 <odyssey4me> how do they compare to the roles we already have in the ops repo?
16:29:54 <andymccr> so my only concern is recreating the wheel when there are already upstream roles for E/L/K individually
16:31:06 <andymccr> happy to adopt the roles if we think thats a better approach - also i agree with evrardjp in that case. seems sensible to just adopt those roles as individual roles
16:31:07 <d34dh0r53> I've switched to using the ansible-elasticsearch role from elastic.co for elasticsearch, we do a ton of custom filtering in logstash and filebeats working on kibana now.
16:31:17 <andymccr> d34dh0r53: ahh awesome
16:31:26 <andymccr> d34dh0r53: how do you integrate the upstream role?
16:31:48 <d34dh0r53> it's a play that lives in openstack-ansible/playbooks in my dev environment
16:32:05 <andymccr> d34dh0r53: that sounds great then ++ for getting those in. i can get the repo's created upstream for those roles and we can start moving that forward
16:32:14 <andymccr> just let me know what repos you need created
16:32:24 <d34dh0r53> awesome! will do
16:32:34 <evrardjp> well if that's directly upstream we won't even need repos for those ones
16:32:43 <evrardjp> so that's even better :D
16:32:45 <andymccr> evrardjp: only elasticsearch is - logstash and filebeat are custom
16:32:50 <andymccr> because its mostly just filters
16:32:53 <evrardjp> yeah that's what I understood
16:32:59 <andymccr> yeah so we'd just need 2 roles at that point i think
16:33:01 <evrardjp> but maybe filters would be vars to existing roles
16:33:06 <d34dh0r53> also, could use suggestions on naming the roles, at this point I have elk-logstash, elk-filebeats and elk-kibana
16:33:23 <evrardjp> in any way, good work!
16:33:26 <andymccr> just openstack-ansible-kibana/filebeat/logstash?
16:33:34 <andymccr> although kibana seems like it may be upstreamable too
16:33:35 <d34dh0r53> that works
16:33:36 <andymccr> at least reasonably easily
16:33:37 <evrardjp> +1 andymccr
16:33:48 <d34dh0r53> yeah, I'll know about kibana today
16:33:53 <andymccr> sweet
16:34:03 <evrardjp> d34dh0r53: do you think it's possible to collaborate with IBM on the kibana dashboards?
16:34:15 <evrardjp> there was a presentation at the summit IIRC
16:34:22 <d34dh0r53> absolutely, I didn't know that
16:34:36 <andymccr> yeah their dashboard looked pretty nice
16:34:48 <logan-> https://www.youtube.com/watch?v=HcKIBVOnVvo
16:34:55 <andymccr> sweet - thanks d34dh0r53. ping me and let me know what repos you need.
16:35:01 <andymccr> logan- cloudnull any other thoughts?
16:35:05 <d34dh0r53> will do, thanks all
16:35:08 * d34dh0r53 drops mic
16:35:44 <logan-> yes one thing
16:35:53 <evrardjp> that would be really cool to have only upstream roles and maintain them ourselves :)
16:36:28 <andymccr> evrardjp: agreed
16:36:33 * cloudnull reading
16:36:46 <evrardjp> and not*
16:36:49 <logan-> if the roles can be generalized enough to where the openstack-ansible specific bits can be configured into the roles via vars, id really consider not naming them openstack-ansible-* roles and try to get more generalized usage of them to get more non-OSA users of them
16:37:12 <odyssey4me> oh yes, I'm very happy with that idea
16:37:14 <andymccr> logan-: yeah agreed - i think for elasticsearch and hopefully kibana it sounds like we will just have playbooks that call the upstream roles.
16:37:16 <logan-> same thing evrardjp is saying I think
16:37:29 <evrardjp> yeah we agree
16:37:36 <d34dh0r53> interesting, although they are fairly tailored for openstack, not necessarily OSA though
16:37:37 <odyssey4me> there's been quite a bit of interest from infra in re-using some of our roles which are more infra focused
16:37:37 <d34dh0r53> ok
16:37:43 <andymccr> logstash as it stands we're not - but i think we may be able to move to just use like https://galaxy.ansible.com/geerlingguy/logstash/ or some equivalent and put down filters
16:37:44 <cloudnull> ++ I agree w/ logan-
16:37:53 <evrardjp> logan-: your roles are a good example :p
16:37:54 <odyssey4me> if they're tailored to openstack, then perhaps they should not be
16:38:16 <andymccr> d34dh0r53: what do we do apart from custom filters that are specific to an OSA/OpenStack logstash?
16:38:19 <cloudnull> the folks at elastic have some roles too
16:38:20 <cloudnull> https://github.com/elastic/ansible-elasticsearch
16:38:20 <odyssey4me> we should be able to feed it config and it should do the right thing
16:38:27 <logan-> i reuse galera, -security, etc outside of OSA so thats why this comes to mind. there would probably be more exposure if some of the roles were named more generally
16:38:30 <andymccr> cloudnull: d34dh0r53 is using those i believe!
16:38:31 <d34dh0r53> andymccr: mostly the filtering
16:38:45 <d34dh0r53> cloudnull: yes, that is the elasticsearch role that I use
16:38:54 <cloudnull> oh, cool .
16:38:54 <andymccr> d34dh0r53: maybe we could just carry the filters then and use an upstream role and dump those down as part of a playbook ro some other task?
16:38:56 <odyssey4me> the filtering should be something we can extract, similar to the haproxy/keepalived roles
16:39:12 <d34dh0r53> there aren't upstream elastic.co roles for logstash or filebeat
16:39:29 <evrardjp> logan-: do you suggest of extracting galera out of the openstack-ansible namespace, like security?
16:39:37 <evrardjp> same for rabbit?
16:39:50 <odyssey4me> yeah, our galera and rabbit roles are actually great compared to the others out there
16:39:51 <logan-> evrardjp: maybe eventually. I think most of the infra roles could go that route tbh
16:40:12 <andymccr> im not opposed to that
16:40:37 <andymccr> lets discuss that at the PTG though :)
16:40:43 <evrardjp> we'd maybe need a different branching scheme, and it needs more thinking. But I agree with the idea. However we have to remove orchestration from the roles then.
16:41:11 <evrardjp> andymccr: indeed, a good discussion for the ptg :)
16:41:20 <andymccr> i think it needs more thought and consideration
16:41:30 <evrardjp> maybe a spec? :p
16:41:32 <andymccr> but i do think our galera role specifically is quite good in comparison to anything else available
16:41:46 <logan-> ++ sounds good
16:41:49 <andymccr> i would love to see a spec if somebody would like to write it ;P
16:42:08 <evrardjp> I see what you did there.
16:42:17 <andymccr> stealth
16:42:31 <evrardjp> I'd like to skip that one though.
16:43:05 <logan-> ill work on it
16:43:07 <evrardjp> maybe we should just put it into action point or something
16:43:09 <andymccr> boom :)
16:43:15 <evrardjp> cool
16:43:24 <andymccr> otherwise we can just start the discussion at the ptg that way somebody who is interested can take it on board!
16:43:26 <andymccr> OK!
16:43:29 <andymccr> #topic open discussion
16:43:45 <andymccr> although we basically were there - anybody have any other topics to discuss?
16:44:50 <andymccr> i'll leave it for a few minutes :)
16:47:12 <evrardjp> I have nothing to add.
16:47:33 <evrardjp> if everybody would do the same, we could close the meeting :p
16:48:34 <odyssey4me> nothing from me
16:48:35 <logan-> same
16:48:36 <d34dh0r53> I'm good
16:49:04 <andymccr> haha
16:49:05 <andymccr> ok cool
16:49:07 <andymccr> #endmeeting