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