16:03:40 <odyssey4me> #startmeeting OpenStack-Ansible
16:03:40 <openstack> Meeting started Thu May  5 16:03:40 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:44 <openstack> The meeting name has been set to 'openstack_ansible'
16:03:47 <odyssey4me> #topic Rollcall & Agenda
16:03:50 <spotz> \o/
16:04:19 <mrhillsman> \o/
16:04:25 <d34dh0r53> o/
16:05:01 <evrardjp> o?
16:05:04 <evrardjp> o/
16:05:07 <jmccrory_> o/
16:05:15 <prometheanfire> o7
16:05:22 <b3rnard0> \o/
16:05:39 <ametts> o/
16:06:15 <eil397> o/
16:06:43 * mhayden woots
16:06:56 <spotz> b3rnard0: !!!!:)
16:07:13 <odyssey4me> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:07:38 <odyssey4me> Welcome back everyone - hope you all enjoyed the summit and have sufficiently recovered. :)
16:08:04 <odyssey4me> #link http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-04-21-16.02.html
16:08:09 <odyssey4me> ^ minutes from the last meeting
16:08:35 <odyssey4me> #action carried item: odyssey4me to add review for the collection of IRR job logs
16:08:54 <odyssey4me> The rest of the action items were completed.
16:09:14 <odyssey4me> #topic Cleanup of Appendix section in docs
16:09:20 <odyssey4me> evrardjp over to you
16:09:25 <evrardjp> thanks
16:09:43 <evrardjp> it's simple: this page http://docs.openstack.org/developer/openstack-ansible/install-guide/app-configfiles.html
16:09:54 <evrardjp> brought confusion in the past
16:10:33 <evrardjp> because the configuration explained in openstack_user_config.yml isn't  what was fully described in the rest of the docs page
16:10:56 <evrardjp> My suggestion: Stop using these examples
16:11:23 <evrardjp> Actions points on this: Remove these examples, and adapt (when necessary) the doc
16:11:51 <evrardjp> Impact: We don't have to worry about these useless files that we carry
16:12:27 <evrardjp> No other impact, at least for now? What's your opinion?
16:12:35 <palendae> So I think having example files is useful in order to give full context
16:12:49 <palendae> In-line snippets in docs can lose stuff like indentation, which people have had problems with before
16:12:59 <Zucan> I wonder if it needs to be tailored more towards "use cases" with some example configs associated with use scases.
16:13:01 <palendae> e.g. network information being under global_ovrrides
16:13:11 <palendae> But I agree that carrying *two* things is a bad idea
16:13:18 <odyssey4me> I fully agree. I've made my thoughts on duplicated documentation quite clear previously. A previous discussion about this resulted in https://review.openstack.org/291310 which removed the networking config example and moves it into docs. I would like to see more of that.
16:13:33 <michaelgugino> ++
16:13:34 <palendae> This did come up at summit, that we carry example files for specfic gate scenarios
16:13:54 <evrardjp> palendae the context for examples is already a part of another of my commits, however insisting on the indentation wasn't
16:13:57 <evrardjp> good point there
16:14:13 <odyssey4me> palendae with use-cases defined properly I will support example configs - but those examples will be used by the gate and therefore properly maintained
16:14:29 <palendae> evrardjp: If the examples can provide at least the headers that the secction is indented under, that's good
16:14:31 <evrardjp> so if I push this goog practice, are we ok for removing the files from the doc ?
16:14:35 <odyssey4me> also the config files should not explain things, that's what docs are for - they're simply samples
16:14:51 <palendae> odyssey4me: Sure, I'm not for having prose in example configs, or full configs in prose
16:14:53 <evrardjp> ok
16:15:02 <odyssey4me> another point of context is that we discussed much of this at length in the summit session https://etherpad.openstack.org/p/openstack-ansible-newton-role-docs
16:15:06 <palendae> And if they're maintained configs, that's cool
16:15:33 <palendae> People learn in different ways, and having only the prose with isolate segments would be confusing for me
16:16:06 <odyssey4me> but for the moment, evrardjp if you'd like to move ahead then please do - it'll take some time for the docs work to come to fruition and the changes you put in will likely merge before they really take full effect
16:16:08 <evrardjp> that's why we have a conversation palendae , good to know
16:16:31 <palendae> Yeah, I won't/can't block it, just sharing my view
16:16:32 <evrardjp> let's try and we'll see, nobody seems against the principle
16:16:47 <odyssey4me> palendae the general drive is that the roles should largely be self documenting by good commenting in the defaults files
16:16:54 <palendae> odyssey4me: Yeah, that's fair
16:16:56 <odyssey4me> the docs then simply include the defaults files
16:17:00 <palendae> Yep
16:17:04 <palendae> I liked that example
16:17:23 <palendae> I seem to be in the minority, worth hearing a different view of it at least
16:17:27 <spotz> Worst comes to worse we do a few folks don't like it and we try something new
16:17:35 <odyssey4me> also the tests done in the roles are supported by documentation which describes the design implemented, and provides included config files to show the example
16:17:52 <odyssey4me> that's the bit we need to work on asap
16:18:02 <odyssey4me> we need to figure out how practical it is to do that
16:18:55 <evrardjp> we took 16% of the meeting with this conversation, let's move on :D
16:19:26 <odyssey4me> lol, ok - moving on
16:19:36 <odyssey4me> #topic Newton Summit Retrospective
16:19:53 <spotz> I thought it went well, lot of new faces
16:20:05 <odyssey4me> I'll try to put my thoughts together and publish a blog post before the next meeting.
16:20:12 <odyssey4me> Any comments/thoughts/questions?
16:21:23 <michaelgugino> no
16:22:03 <evrardjp> I'll wait for the blog post then
16:22:42 <odyssey4me> alright, moving on
16:22:44 <odyssey4me> #topic Release Planning and Decisions
16:22:55 <odyssey4me> Kilo 11.2.15 has just been tagged
16:23:17 <odyssey4me> Does anyone know of any reason not to tag Mitaka 13.0.2 and Liberty 12.0.12 today?
16:23:37 <evrardjp> None
16:24:09 <odyssey4me> I mean, besides https://review.openstack.org/309511 not merging yet. :p
16:24:28 <odyssey4me> now that it's passed the gate, please can I get some core reviews on that
16:24:33 <prometheanfire> :P
16:24:47 <odyssey4me> jmccrory automagically cloudnull d34dh0r53 stevelle mattt hughsaunders andymccr ^
16:26:37 <cloudnull> odyssey4me: done
16:27:01 <odyssey4me> ok, moving on - I'll request the tags later
16:27:06 <odyssey4me> #topic Ubuntu 16.04 LTS Support
16:27:37 <odyssey4me> #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:28:06 <odyssey4me> need another review on https://review.openstack.org/#/c/286282/
16:28:08 <michaelgugino> I'm working on galera_server as we speak
16:28:33 <odyssey4me> michaelgugino thanks - please assign it to yourself under the 'SystemD Support work item
16:29:21 <cloudnull> I've got much of the systemd init bits worked out, i'd be happy to throw up an initial review for the os.* roles.
16:29:28 <michaelgugino> ok.  I plan on doing galera_client this week (as it will be needed by galera_server)
16:29:49 <cloudnull> if someone already has something on that too, maybe we can combine efforts and tackle it across the OS roles
16:30:02 <odyssey4me> cloudnull cool - can you assign yourself to the roles in the etherpad to ensure that everyone else is aware that you're on it
16:30:08 <michaelgugino> rabbitmq 16.04 support after jimmy's patch hits
16:30:09 <evrardjp> FYI I'm trying to contact keepalived package maintainers for 16.04 support
16:30:19 <odyssey4me> or assign one on it as you start work on it
16:30:22 <evrardjp> no news yet
16:32:26 <michaelgugino> okay, I put my name next to a couple items there
16:32:51 <cloudnull> i'll tackle glance first.
16:33:03 <cloudnull> i think keystone we'll get for free because it uses apache
16:33:15 <michaelgugino> cloudnull: keystone would be useful as other roles depend on it working
16:33:25 <michaelgugino> that's why I'm trying to hit galera_server and client first
16:34:10 <cloudnull> indeed. i think its just a change in the apache layout for multi-distro, so ill bang on that too
16:34:57 <michaelgugino> cloudnull: I have tested the new container_create locally, it's working great.
16:35:07 <odyssey4me> cloudnull alright, please note which ones you're taking on in the ether pad and add review links once you have them up
16:35:09 <cloudnull> awesome
16:35:31 <odyssey4me> lol, I see you're aiming right at the bootom section
16:35:46 <odyssey4me> who needs interim steps when you can do it all at once :p
16:35:54 <spotz> hehe
16:36:37 <cloudnull> the bulk of the work will need to be done in the systemd detection and unit files
16:36:47 <cloudnull> the infra section is largely done by the packages we install
16:37:28 <cloudnull> so i'd  like to get a pattern up for us to all agree on and follow in the bulk of the os_* roles
16:37:42 <odyssey4me> yeah, agreed - it would be nice to have a sample to work from
16:37:44 <spotz> +1
16:38:32 <odyssey4me> if anyone's looking for things to do there are still roles outstanding for the simple application of the pattern to implement different var sets fot different os's
16:38:43 <odyssey4me> the first set in the work breakdown has around 10 roles left
16:39:44 <stevelle> I might pick up a few of those
16:39:45 <spotz> odyssey4me: I'm good at simple hacking let me go look
16:40:33 <odyssey4me> great, thanks - we need to get that done in the next two weeks or so
16:41:10 <odyssey4me> alright, moving on
16:41:13 <odyssey4me> #topic Ansible 2.1 Support
16:41:18 <odyssey4me> jmccrory are you around?
16:41:22 <jmccrory> yep
16:42:03 <odyssey4me> we discussed at the summit running the rc for 2.1 but maintaining compatibility to ensure that we could fall back if it doesn't release this cycle
16:42:32 <odyssey4me> what do you think the best way to go about doing this would be?
16:42:47 <jmccrory> could an experimental 2 job be added for integrated gate?
16:42:52 <odyssey4me> we could add a non-voting Ansible 2.1 job for the integrated gate
16:43:19 <odyssey4me> heh, snap - although I think it better that we do a non voting check so that we see the results for every patch
16:43:26 <michaelgugino> we also mentioned 2.1 in a venv
16:43:33 <jmccrory> ah even better
16:43:41 <evrardjp> that's interesting to have a view of the 2.1 status
16:44:01 <odyssey4me> well, for the gate check it's not relevant whether it's in a venv or not
16:45:46 <michaelgugino> we discussed supporting the venv via the openstack-ansible command, IIRC.  I agree, let's not hold up the gate check for such a reason.
16:45:53 <odyssey4me> I'm trying to find cloudnull's patch to make ansible go into a venv
16:46:08 <jmccrory> https://review.openstack.org/#/c/304840/ - venv patch
16:46:16 <odyssey4me> thanks jmccrory
16:47:43 <odyssey4me> I think that's a great developer tool, but I am a little concerned about perpetuating that into production.
16:48:02 <odyssey4me> It seems like we're moving away from using Ansible in the way Ansible is typically used. That causes confusion.
16:49:09 <cloudnull> odyssey4me:  ++ it takes away the root ansible command .
16:49:16 <cloudnull> well it puts it into a venv
16:49:27 <cloudnull> you cant really have it both ways
16:49:55 <odyssey4me> yeah, I'm inclined to say that this is better than our current scenario
16:50:13 <cloudnull> you can activate the venv if you want to run stock ansible commands
16:50:45 <cloudnull> or pass the --adhoc, --galaxy, --playbook (default) if you want to execute using the helper
16:51:37 <michaelgugino> venv's are not that complicated and are pretty ubiquitous in the Python world.  I think it will be helpful overall.
16:52:14 <cloudnull> ++
16:52:15 <evrardjp> michaelgugino venvs already work without the need of this wrapper tool
16:52:27 <evrardjp> it's just convenient for our dev work
16:52:46 <cloudnull> well no. openstack-ansible is how we run all of the commands.
16:52:51 <evrardjp> I think the principle isn't bad, I just think we need to properly explain what's behind the seen to not make it a obscure way of doing
16:52:57 <cloudnull> so openstack-ansible needs to be able to execute the venv
16:53:06 <palendae> evrardjp: That was my first response too :p
16:53:26 <palendae> https://review.openstack.org/#/c/304840/24/doc/source/developer-docs/scripts.rst talks about that fwiw
16:53:32 <cloudnull> I did update the docs
16:53:32 <michaelgugino> I'm not sure I like the idea of bind mounting
16:54:07 <palendae> Comments on the review could go on the review itself; will help track down discussion around it in the future :)
16:54:11 <odyssey4me> michaelgugino it's optional
16:54:13 <michaelgugino> I think that is a fix for dynamic inventory, perhaps we can have dynamic inventory read an env variable if set
16:54:31 <odyssey4me> yeah, so I think this needs some review attention please
16:54:37 <odyssey4me> let's discuss it all in there
16:54:43 <michaelgugino> k
16:54:46 <cloudnull> yea, michaelgugino im not a fan of that but i wanted to provide something for the multi-deployment / config scenario.
16:54:52 <evrardjp> I don't disagree on this commit, I'm just afraid of splitting the community from ansible's a little more
16:55:09 <cloudnull> sadly we have a lot of hard coded references to /etc/openstack_deploy
16:55:30 <cloudnull> if we can fix that ^ i'd be happy to see that code never see the light of day
16:55:49 <evrardjp> cloudnull maybe this is what should be solved, be more flexible with user changes
16:56:29 <cloudnull> i think we could spend an entire cycle on just that.
16:56:34 <evrardjp> :D
16:56:48 <cloudnull> which wouldnt be bad
16:56:50 <cloudnull> IMHO
16:57:31 <palendae> I started down cleaning some of that up in the dynamic_inventory.py file yesterday, but it was making my patch set too big and unfocused
16:57:47 <palendae> Won't completely remove the hard coding, but will clarify things
16:57:53 <michaelgugino> I don't think that much run-time code is referencing /etc/openstack_deploy, definitely setup scripts, but that's outside the scope of adding an additional env.
16:58:36 <palendae> Yeah
16:58:38 <cloudnull> i think dynamic_inventory is the key to releasing our dependency on  a lot of that.
16:58:56 <odyssey4me> agreed
16:58:59 <evrardjp> agreed
16:59:04 <palendae> Indeed
16:59:25 <evrardjp> 40 seconds!
16:59:29 <odyssey4me> should we isolate some time in the next meeting to discuss and put together some sort of basic idea of the things we want out of the dynamic inventory next version?
16:59:30 <spotz> hehe
16:59:54 <palendae> odyssey4me: I would like to hear specific proposals around changes for multiregion
17:00:13 <palendae> I think automagically was going to put something together for that, but not sure
17:00:18 <odyssey4me> ok, we're out of time
17:00:18 <palendae> I'll be out so I'll have to catch the notes
17:00:21 <odyssey4me> thanks all for coming
17:00:25 <odyssey4me> #endmeeting