16:00:48 <odyssey4me> #startmeeting OpenStack Ansible Meeting
16:00:49 <openstack> Meeting started Thu Nov 12 16:00:48 2015 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:53 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:04 <prometheanfire> \o
16:01:25 <cloudnull> o/
16:01:29 <hughsaunders> hey
16:01:29 <mattt> o/
16:01:32 <d34dh0r53> o/
16:01:45 <BjoernT> o/ ?
16:01:54 <andymccr> o/
16:01:55 * palendae waits for rollcall
16:02:14 <hughsaunders> BjoernT: not sure if you're here?
16:02:25 <BjoernT> yes
16:02:59 <odyssey4me> lol, whoops
16:03:15 <odyssey4me> #topic Agenda & rollcall
16:03:35 <palendae> Hello!
16:03:38 <d34dh0r53> o/
16:03:46 <oneswig> \o
16:03:47 <KLevenstein> o/
16:03:49 <cloudnull> o/ v2
16:04:11 <cloudnull> welcome oneswig
16:04:18 <prometheanfire> \o
16:04:28 <oneswig> cloudnull: thanks, first tiem
16:04:40 <prometheanfire> we'll be gentle
16:05:07 <odyssey4me> welcome oneswig :)
16:05:17 <odyssey4me> right, let's get the show on the road
16:05:20 <odyssey4me> #topic Review action items from last week
16:05:32 <odyssey4me> except it wasn't last week, or the week before (summit week)
16:05:35 <Sam-I-Am> moo.
16:05:42 <odyssey4me> #link http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2015/openstack_ansible_meeting.2015-10-22-16.02.html
16:06:00 <odyssey4me> no action items, so all is well
16:06:14 <odyssey4me> #topic Items in progress or otherwise in need of work
16:06:35 <odyssey4me> #topic Installation guide blueprint
16:06:49 <odyssey4me> KLevenstein Sam-I-Am ^ your topic :)
16:06:53 <Sam-I-Am> yup
16:07:04 <cloudnull> what say you ?! :)
16:07:08 <Sam-I-Am> KLevenstein: moo?
16:07:29 <Sam-I-Am> ok...
16:07:32 <Sam-I-Am> so here's the thing
16:07:37 <KLevenstein> mostly I wanted to call attention to it
16:07:44 <Sam-I-Am> oh, there she is
16:07:46 <KLevenstein> since I think it’s important
16:08:13 <odyssey4me> it is :)
16:08:28 <odyssey4me> are we looking for volunteers to make it happen? or further input of some sort?
16:08:33 <Sam-I-Am> further input
16:08:34 <KLevenstein> it’s also relevant to various things we’re trying to manage from the rpc-openstack side
16:09:02 <Sam-I-Am> the direction it takes (and o-a in general) impacts rpc-openstack
16:09:39 <Sam-I-Am> the original plan was to more or less point to or consume the o-a docs for the generic installation bits... the rpc docs merely augment it with rpc-specific things
16:09:39 <odyssey4me> #link http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/install-guide.html
16:10:07 <Sam-I-Am> however, it seems like o-a is taking a turn toward not being opinionated or fully deployable... just modules to consume.
16:10:43 <odyssey4me> not exactly, but continue
16:10:52 <Sam-I-Am> well thats the problem
16:10:59 <Sam-I-Am> docs doesnt really know whats happening with o-a
16:11:05 <cloudnull> Sam-I-Am:  no, OSA will break the modules out but the repo will still continue to be deployable
16:11:41 <KLevenstein> we could use input on the spec, then, for more clarity on what needs to be documented, and how.
16:11:59 <cloudnull> 's/modules/roles/'
16:12:01 <Sam-I-Am> we're trying to figure out if we should create (or continue to maintain) an entirely separate install guide for rpc that covers all of the things rpc needs... or expect that we can consume the o-a install guide.
16:12:12 <Sam-I-Am> cloudnull: submodules?
16:12:19 <odyssey4me> KLevenstein ah, I think when the spec was approved it seemed to cloudnull and I that the work was already in mind - it wasn't clear that there was a desire for input
16:12:23 <cloudnull> #/kickban Sam-I-Am
16:12:45 <cloudnull> :)
16:12:50 <odyssey4me> ok, so if I may I can clarify the general direction
16:12:52 <Sam-I-Am> odyssey4me: i wrote the spec when people were out on the assumption that o-a was keeping a conventional install guide that installs an opinionated-enough system that works
16:13:12 <cloudnull> ^ Sam-I-Am that should continue
16:13:29 <KLevenstein> (fwiw I believe we should treat the OA installation documentation and the rpc-openstack documentation as completely separate documents.)
16:13:43 <odyssey4me> effectively the roles, playbooks and scripts in the repository(ies) are tools in a toolbox for deployers to use as they choose
16:14:17 <cloudnull> Sam-I-Am: the role movement will have no effect on the deploy-ability of the OSA project.
16:14:20 <odyssey4me> as per the spec in http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/gate-split.html the repository will still provide meta plays to showcase how to use everything to implement well known use cases
16:15:28 <odyssey4me> there will need to be pre-role documentation for OSA to describe the options for configuring the roles... I would guess that you would not want to duplicate these docs in rpc-openstack
16:15:33 <odyssey4me> *per role
16:15:50 <KLevenstein> odyssey4me: okay, the spec should capture that type of information
16:15:56 <Sam-I-Am> the idea was minimizing duplication and places to track changes
16:16:05 <Sam-I-Am> if its not specific to rpc, it resides in the o-a docs
16:16:06 <odyssey4me> there will also need to be documentation for how to use the tooling to setup your environment - essentially the basic install guide we now have
16:16:22 <Sam-I-Am> therefore if o-a docs change, the rpc docs follow
16:16:37 <odyssey4me> so I agree with cloudnull here, the existing install guide provides value to OSA and will continue too
16:17:15 <Sam-I-Am> ok. question is... can we expect it to be maintained?
16:17:21 <odyssey4me> and it would be awesome to have rpc-docs working on OSA docs as upstream and then only looking at specific RPC opinionations in a different docs location
16:17:30 <Sam-I-Am> there's still some rax technical debt in it (such as the architecture)
16:17:44 <odyssey4me> Sam-I-Am yes, thus far the maintenance has been done by the community, for the community
16:18:10 <odyssey4me> we could do with some help making it pretty, as it's become an organic growth mess
16:18:19 <Sam-I-Am> true. does it work still?
16:18:44 <odyssey4me> or even not pretty, but to keep it simple and validated on an ongoing basis
16:18:57 <Sam-I-Am> it sort of has fallen by the wayside
16:19:15 <Sam-I-Am> hence the spec... effort to figure out how to make it both useful and easier to maintain?
16:19:19 <odyssey4me> we've had many patches in the last few months from people working through them and validating them, so I expect that it still works
16:19:23 <KLevenstein> odyssey4me: I think if we (rpcdocs, and anyone else) have a clearer idea of what needs to be added/maintained in OA, it’ll—yes, what Sam-I-Am said
16:19:35 <odyssey4me> a large proportion of the specs since the liberty release has been docs
16:19:50 <KLevenstein> so I’d like to see the spec enhanced a bit with things like what you said: add pre-role documentation, etc.
16:20:17 <Sam-I-Am> basically i'm looking for more info on recommended structure
16:20:20 <odyssey4me> ok, perhaps we can set aside half of next thu's meeting to work through that in an etherpad, with discussion?
16:20:27 <Sam-I-Am> right now the docs are more or less a copy of what we had for rpc
16:20:47 <odyssey4me> basically if you guys can facilitate a structured discussion then we can focus energy on it with a productive outcome
16:20:47 <cloudnull> or maybe we carry that convo into the channel ?
16:21:04 <Sam-I-Am> or that
16:21:12 <KLevenstein> odyssey4me cloudnull: I approve
16:21:33 <cloudnull> but an etherpad to outline all the things would be great .
16:21:34 <KLevenstein> I can set up an etherpad
16:21:40 <cloudnull> sweet
16:21:52 <odyssey4me> yeah, we can chat after the meeting a bit - but I think that a structured and prepared for discussion that's facilitated would be most productive - which needs the time to prep
16:22:05 <KLevenstein> here you go: https://etherpad.openstack.org/p/oa-install-docs
16:22:21 <odyssey4me> #link https://etherpad.openstack.org/p/oa-install-docs
16:22:59 <Sam-I-Am> yay
16:23:01 <odyssey4me> ok, so we can work up a framework and put Q&A's in during the next week - then can we have a volunteer to actually facilitate the finalisaiton of it in next week's meeting?
16:23:51 <odyssey4me> KLevenstein would you be happy to do so?
16:23:55 <Sam-I-Am> i may not be around for next week's meeting
16:23:55 <KLevenstein> sure
16:24:05 <odyssey4me> great, thanks!
16:24:32 <odyssey4me> #action KLevenstein to facilitate a discussion for documentation improvements in the next community meeting
16:25:09 <odyssey4me> #action all to contribute to https://etherpad.openstack.org/p/oa-install-docs with thoughts/ideas/questions ahead of the workshop
16:26:09 <odyssey4me> alright, we have no other specific topic at hand on the agenda but I did want to make sure that we have some open discussion
16:26:18 <odyssey4me> #topic Open discussion
16:26:38 <palendae> I'd appreciate people's thoughts on https://review.openstack.org/#/c/242225/
16:27:15 <mattt> palendae: no immediate feedback, other than thank you
16:27:54 <palendae> It's gonna require some work; I'd really like to get to the point where tests can just import the dynamic inventory, but I think that'll have to be done in steps
16:27:59 <odyssey4me> palendae I haven't looked in too much detail, but a few thoughts
16:28:27 <odyssey4me> one is that the general standard for tests in openstack projects appears to be to use the directory 'tests', not 'test' - so that'd be good to change
16:29:29 <odyssey4me> also, I think that we're going to end up with a variety of tests with other files needed, like this - so I'd suggest an extra subfolder with a name that matches the tox env name - does that make sense?
16:30:16 <palendae> Yeah. We're also going to need different files for inventory tests, because testing with the AIO example files is just 1 case
16:30:24 <odyssey4me> ie put all files into tests/inventory/
16:30:40 <cloudnull> palendae:   I think that change is great as a first step to generally improving our inventory bits
16:30:43 <odyssey4me> ah sure, but perhaps that can be an additional case added afterwards
16:30:46 <cloudnull> so thank you ++
16:30:54 <palendae> odyssey4me: Right, I'm not adding those right now
16:31:02 <palendae> But they'll be needed
16:31:42 <odyssey4me> I'm pretty sure that there could be a lot more tests implemented for the dynamic inventory.
16:31:56 <palendae> Absolutely
16:32:14 <mattt> did we hit any issues in the past w/ the inventory that we haven't accounted for yet?
16:32:21 <mattt> i know the dupe IP thing was the obvious
16:32:31 <odyssey4me> mattt TDD doesn't work like that :p
16:33:06 <palendae> mattt: One that may be a candidate https://bugs.launchpad.net/openstack-ansible/+bug/1512883
16:33:06 <openstack> Launchpad bug 1512883 in openstack-ansible "Host name of haproxy in openstack_user_config.yml causes recursion error" [Undecided,Confirmed]
16:33:21 <palendae> Though I've not really dug into that
16:35:00 <odyssey4me> one of the goals for this cycle is to increase test coverage to improve code quality
16:35:12 <mattt> we should do this for every bit of python that we have in openstack-ansible
16:35:19 <mattt> all the modules that we're carrying etc.
16:35:34 <odyssey4me> so it'd be great if those interested could spend some cycles considering how best to do some of that
16:35:35 <mattt> so i think this is a great start
16:36:12 <cloudnull> mattt: ++ i think once we find a place for the libs/plugins to live outside of the main repo we can embark on adding tests and such
16:36:33 <odyssey4me> this also comes into play for improving infrastructure upgrades - for example, before upgrading - run some tests to confirm that the environment is actually in good working order
16:36:40 <cloudnull> also there's a lot of work happening in ansible for v2.0 interms of openstack libs to manage installs
16:36:50 <odyssey4me> then afterwards, do another test to confirm that stuff's not broken
16:36:51 <palendae> I think ideally the inventory will become a lib that could stand alone, too
16:36:52 <cloudnull> we might want to see what we can begin using there.
16:36:57 <palendae> But that may be a long way off
16:37:34 <odyssey4me> so we need to think about tests in layers - unit, functional, etc
16:39:56 <odyssey4me> alright, anyone else got something they want to raise?
16:40:27 <mattt> the neutron db migrations change, if someone has time to test
16:40:31 <mattt> (pulling up the review now)
16:40:41 <mattt> https://review.openstack.org/#/c/240560/
16:41:13 <pabelanger> ohai
16:41:16 <cloudnull> ++ https://review.openstack.org/#/c/241483/ -- when people have time
16:41:18 <pabelanger> sorry I am last
16:41:21 <pabelanger> laste*
16:41:22 <pabelanger> grr
16:41:28 <cloudnull> o/ hi pabelanger
16:42:00 <odyssey4me> pabelanger o/ and welcome
16:42:49 <odyssey4me> we're currently in open discussion, so feel free to introduce yourself and present anything for discussion
16:43:03 <pabelanger> Since it is open discussion, let me do intros.  Name is Paul Belanger, work at Red Hat. Looking to help contribute to ansible more. Been working with openstack-infra for the last 3.5 years, so I want to help improving the testing infra for ansible (roles)
16:43:34 <cloudnull> welcome  !
16:43:45 <pabelanger> So, over the next few days. I'll likely be asking questions / helping to move all the ansible roles to a common test format.  For example, tox -eansible-lint
16:43:52 <odyssey4me> pabelanger yeah, I've tried to engage on that topic with infra a few times but the interest is small, so your collaboration is welcome!
16:43:57 <pabelanger> talking to cloudnull last night, seem we both share a common goal
16:44:07 <cloudnull> ++
16:44:50 <pabelanger> odyssey4me: Ya, for sure.  Personally, I have an unofficial project at https://github.com/openstack/ansible-role-nodepool and have plans to build out testing for it.  If we can share testing stuff, I think it will be great
16:44:50 <oneswig> As a general question of direction, is the long-term aim to have modules that provide mechanism and configuration data to implement policy?  It looks like this is the way the project is driving?
16:45:50 <odyssey4me> pabelanger agreed, the more we can help each other the better
16:46:19 <odyssey4me> oneswig if I understand what you mean - that is currently how everything's designed but we're driving to make that clearer
16:46:36 <pabelanger> great. So, like I said. I'll likely be asking some questions in the coming days and help bridge the effort between openstack-ansible and openstack-infra :)
16:47:14 <oneswig> odyssey4me thanks I'm interested in using OSA to explore different configs and seeing the effect
16:47:29 <odyssey4me> oneswig right now it seems like everything's tightly coupled, even though all roles are usable independently - we're splitting the roles out into their own repositories to clarify that they're independently usable, but the playbooks also form two functions
16:47:41 <pabelanger> But with that, I have to run.  Need to walk daughter to school.
16:48:14 <odyssey4me> one function is that we have playbooks which do certain functions - like install keystone on multiple hosts, or build containers on multiple hosts
16:48:25 <odyssey4me> awesome, thanks pabelanger
16:48:53 <odyssey4me> those playbooks can be seen as kind-of an API within the project... they can get consumed by meta-playbooks
16:49:30 <odyssey4me> the meta-playbooks may be built by deployers to mix and match things as they want, but we also include meta-playbooks which cover the use-cases we test with and support
16:49:55 <oneswig> odyssey4me this sounds like just what I am looking for, thanks
16:49:59 <odyssey4me> then we have configuration, which we split entirely out of the code tree - and only provide samples and docs in tree
16:50:59 <odyssey4me> oneswig great!
16:51:17 <odyssey4me> anyone else wish to raise anything?
16:51:31 * Sam-I-Am raises a beer
16:54:21 <odyssey4me> alright, thank you all for your time :)
16:54:25 <odyssey4me> #endmeeting