16:02:37 <odyssey4me> #startmeeting OpenStack Ansible Meeting
16:02:37 <openstack> Meeting started Thu Dec 10 16:02:37 2015 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:40 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:02:44 <prometheanfire> hi
16:02:44 <cloudnull> o/
16:02:46 <Sam-I-Am> moo
16:02:53 <odyssey4me> #topic Agenda & rollcall
16:03:01 <palendae> o/
16:03:16 <odyssey4me> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:04:40 <cloudnull> presente
16:04:42 <KLevenstein> o/
16:04:58 <njohnston> o/
16:05:02 <javeriak_> o/
16:05:04 <prometheanfire> 0/
16:06:23 <jreeves> o/
16:06:50 <odyssey4me> welcome everyone - no action items from last week, so we can head onwards
16:07:00 <Bjoern_> o/
16:07:00 <odyssey4me> #topic Topics for Discussion
16:07:12 <odyssey4me> #topic Independent repository for plugins and libraries
16:07:17 * odyssey4me hands the mic to cloudnull
16:07:43 <cloudnull> hi
16:08:12 <cloudnull> so i would like to know how we should handle libs and plugins
16:08:22 <cloudnull> within our new independent role repos approach
16:08:32 <cloudnull> lots of the roles need access to the libs
16:08:40 <cloudnull> and i'd like to not copy them all over the place
16:09:16 <palendae> You're talking about the openstack service libs? Would a logical place be their associated role?
16:09:33 <cloudnull> at present i've been doing this https://github.com/openstack/openstack-ansible-galera_server/blob/master/tests/ansible-role-requirements.yml#L1-L4
16:09:48 <cloudnull> palendae:  the keystone, neutron, etc
16:09:51 <cloudnull> for ansible
16:09:51 <odyssey4me> palendae if they're only used by that role, yes - but we have cross-role libs
16:09:58 <javeriak_> what kind of plugins are we talking about, service plugins?
16:10:07 <cloudnull> javeriak_:  https://github.com/os-cloud/openstack-ansible-plugins
16:10:10 <cloudnull> those ones
16:10:26 <palendae> Ah, right, we have them up higher now so Ansible can see them across the roles
16:10:37 <cloudnull> which is a collection of https://github.com/openstack/openstack-ansible/tree/master/playbooks/library and https://github.com/openstack/openstack-ansible/tree/master/playbooks/plugins
16:10:46 <palendae> Dependencies could help with that, no?
16:10:58 <cloudnull> palendae:  ansible doesnt have deps for libs and plugins sadly
16:11:15 <palendae> cloudnull: I thought you could put a lib/plugin in a role and it'd be counted through role deps
16:11:21 <palendae> Or does their lookup not account for that?
16:11:22 <cloudnull> so we can submodule or do something similar to what i've done in the role requirements file
16:11:34 <cloudnull> palendae:  we can add it to a role
16:11:41 <cloudnull> but then we have to add it to all the roles
16:11:44 <palendae> Ok
16:11:46 <cloudnull> or submodule etc
16:11:48 <palendae> So it's scoped to the role
16:11:53 <cloudnull> yes
16:11:58 <javeriak_> cloudnull, you're also trying to upstream the genetric ones to ansible i believe
16:12:02 <palendae> Ansible won't use it's role deps to search for libs
16:12:16 <cloudnull> javeriak_:  yes
16:12:33 <odyssey4me> the advantage of using https://github.com/openstack/openstack-ansible-galera_server/blob/master/tests/ansible-role-requirements.yml#L1-L4 to me is that we never have to manage submodules in each of the repositories... we can fix to a sha if we want to, but don't have to
16:12:44 <cloudnull> so we have to have a place to put them if the new independent roles are to be used as stand alone roles
16:13:42 <cloudnull> So I wanted to poll everyone and see what they thought was best.
16:13:56 <cloudnull> Submodule, ansible role requires , other?
16:14:03 <odyssey4me> my initial feel was that perhaps we could do thing differently (eg: make the utility container to interact with keystone, neutron, etc) to isolate where the libraries are needed... but we need the config_template library everywhere... so that's off the table
16:14:37 <BjoernT> are we caching those roles on the repo server ?
16:14:39 <cloudnull> We also need the other  plugins throughout the stack
16:15:30 <cloudnull> Bjoernt no. The libs and plugins exist within the main git tree
16:15:37 <palendae> I think the role-requirements file makes sense
16:15:43 <odyssey4me> cloudnull yep, there are some others that are needed... and while we should endeavour to upstream them, we also need the flexibility of having them around as an interim step to allow us to keep moving forward
16:16:10 <prometheanfire> so, vendoring?
16:16:23 <javeriak_> using ansible role requirements seems like the cleaner approach to me; but that would incur maintaining a seperate repository for these now
16:16:24 <cloudnull> So I'm good with whatever we deem is best. I just would like a group consensus.
16:16:33 <BjoernT> I would prefer anything over git submodule :-)
16:16:46 <cloudnull> Javeriak_ yes it would.
16:17:05 <cloudnull> I've not proposed the new repo yet because I wasn't sure what to do with them.
16:17:25 <prometheanfire> I personally prefer using the role reqs as well
16:17:56 <javeriak_> well the OSA project is growing, like the others, we will at some point have to separate sub-repos
16:18:01 <odyssey4me> shall we do a vote?
16:18:26 <odyssey4me> although, there are no objections to the role reqs approach so far... do we need to bother voting?
16:18:39 <odyssey4me> are there any specific objections to the role reqs approach?
16:18:53 <javeriak_> aw... i was hoping to see the vote bot again...
16:18:59 <cloudnull> Hahaha
16:19:09 <palendae> javeriak_: Yeah, I'm not super happy about more repos, but at the same time, we're going to be making a lot of repos anyway, a single one's probably not that big of a deal in that case
16:19:15 <cloudnull> Odyssey4me .doit()
16:19:42 <prometheanfire> cloudnull: .net?
16:19:42 <odyssey4me> heh, ok
16:19:43 <javeriak_> palendae agreed
16:20:05 <odyssey4me> #vote Shall we use the role requirements approach for plugins & libs? yes, no
16:20:16 <odyssey4me> bah, I'm no good at this
16:20:16 <palendae> #vote yes
16:20:24 <odyssey4me> #startvote Shall we use the role requirements approach for plugins & libs? yes, no
16:20:24 <openstack> Begin voting on: Shall we use the role requirements approach for plugins & libs? Valid vote options are yes, no.
16:20:26 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
16:20:26 <palendae> #vote yes
16:20:32 <palendae> #vote yes
16:20:34 <cloudnull> #vote yes
16:20:34 <javeriak_> #vote yes
16:20:35 <odyssey4me> #vote yes
16:20:41 <prometheanfire> #vote yes
16:21:05 <cloudnull> Somebody vote no just because. ;-)
16:21:14 <BjoernT> #vote yes
16:21:16 <prometheanfire> one of us one of us
16:21:23 <prometheanfire> cloudnull: you're someone
16:21:43 <cloudnull> I'm nobody.
16:21:53 <andymccr> #vote no
16:21:54 <andymccr> boom
16:22:06 <cloudnull> Hahaha !
16:22:12 <odyssey4me> #endvote
16:22:13 <openstack> Voted on "Shall we use the role requirements approach for plugins & libs?" Results are
16:22:14 <openstack> yes (6): palendae, odyssey4me, BjoernT, prometheanfire, cloudnull, javeriak_
16:22:15 <openstack> no (1): andymccr
16:22:17 <cloudnull> Andymccr for prez!
16:22:22 <andymccr> I'm a visionary
16:22:22 <odyssey4me> lol
16:22:35 <BjoernT> or terrorist
16:22:36 <Sam-I-Am> andymccr: trump
16:22:41 <odyssey4me> right, another question was whether we do one repo or two
16:22:42 <cloudnull> OK I'm done.
16:22:49 <andymccr> i'll be proved right in 2 weeks time!!
16:22:50 <javeriak_> that was fun :), i know what my fav part of these meetings is now..
16:22:57 <andymccr> (or we'll all forget that i said anything)
16:23:14 <cloudnull> I think the single new repo is the best approach.
16:24:01 <javeriak_> yep, more is usually harder to maintain..
16:24:14 <odyssey4me> yeah, after reviewing https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py I see that there are no defaults paths in /etc/ansible for plugins or libraries... so I'm happy with a single repo and the paths referenced in ansible.cfg
16:24:19 <cloudnull> I would also like to limit the repo sprawl.
16:25:06 <odyssey4me> some of the roles could possible consolidate ;)
16:25:15 <odyssey4me> but that's another story, let's not go there
16:25:30 <palendae> cloudnull: We could put them all in one repo! :)
16:25:30 <javeriak_> would the new repo be under /openstack too?
16:25:55 <palendae> javeriak_: I believe so, cloudnull's got stuff in to the infra team to create them
16:26:17 <odyssey4me> palendae the new repositories are already there
16:26:36 <odyssey4me> https://github.com/openstack/?utf8=%E2%9C%93&query=openstack-ansible
16:26:36 <palendae> Cool
16:27:08 <odyssey4me> all the way through to 'setup-infrastructure' is there - the next roles to move over are the openstack roles
16:27:17 <javeriak_> wow...
16:27:40 <odyssey4me> each role has testing focused on that specific role, so the feedback time is much shorter
16:27:42 <cloudnull> Yup. Once https://review.openstack.org/#/c/255921/ goes through its off to the openstack roles.
16:28:54 <odyssey4me> ok, so one repo it is - unless there are any objections within the next two mins
16:29:04 <javeriak_> btw is the documentation in place, the deployment flow will change now i believe?
16:29:06 <odyssey4me> (one repo for the plugins and libs)
16:29:39 <odyssey4me> javeriak_ the deployment flow doesn't actually change - the entry points are the same
16:29:46 <odyssey4me> where stuff goes changes
16:30:06 <odyssey4me> the result is also the same
16:30:13 <javeriak_> so we're still cloning openstack-ansible and role-requirements will pull in the rest
16:30:22 <cloudnull> Yes
16:30:22 <odyssey4me> yep
16:30:26 <javeriak_> ok cool
16:30:56 <cloudnull> The change is simply where the role code lives in terms of a full stack deployment.
16:30:56 <odyssey4me> what's also nice is that each role's individual test method shows how to consume them without the dynamic inventory
16:31:26 <odyssey4me> but yeah, I would like to spend some time beefing up each role's docs a bit - as developer orientated documentation
16:31:38 <cloudnull> We will also be able to create role specific docs. In the future.
16:32:10 <cloudnull> https://wiki.openstack.org/wiki/OpenStackAnsible
16:32:33 <cloudnull> I updated it yesterday for the roles we split out.
16:32:42 <cloudnull> But I'll need to add the new ones.
16:32:47 <logan-> with IRR are the roles going to be pulled in to /etc/ansible/roles during bootstrap-ansible like the role-requirements currently work?
16:32:52 <cloudnull> Role docs are limited currently.
16:33:08 <odyssey4me> logan- yes
16:33:56 <logan-> ok thanks
16:36:13 <odyssey4me> ok, next topic
16:36:22 <odyssey4me> #topic Mid Cycle Meetup
16:36:31 <odyssey4me> #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/081847.html
16:36:38 <odyssey4me> #link http://lists.openstack.org/pipermail/openstack-operators/2015-December/009154.html
16:38:06 <odyssey4me> Please can we have everyone respond to the email indicating your interest.
16:38:43 <odyssey4me> This doesn't have to be considered a firm RSVP, so don't worry about that - it's just simply a 'are you interested?' email.
16:38:46 <cloudnull> ++ replied already
16:41:20 <cloudnull> next!
16:42:05 <odyssey4me> alright,
16:42:09 <odyssey4me> #topic Open discussion
16:42:25 <odyssey4me> Other than the call for input in https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting we have nothing further planned
16:42:34 <odyssey4me> is there anything specific anyone would like to discuss?
16:44:07 <odyssey4me> heh, a quiet bunch today then :)
16:44:15 <Sam-I-Am> yep
16:44:26 <palendae> I've got nothing else
16:44:34 <prometheanfire> odyssey4me: hi
16:44:58 <prometheanfire> you said to bring this up thursday
16:45:01 <prometheanfire> https://review.openstack.org/#/c/253702/
16:46:02 <odyssey4me> ah yes, sure
16:46:27 * odyssey4me hands prometheanfire the mic
16:46:44 <prometheanfire> the patch pulls comments out, stored in an ordered list, then inserts them before the regenerated 'data'
16:47:12 <prometheanfire> it's useful for commented out key value options and general notes people leave in the config
16:47:37 <prometheanfire> I've brought it up with support and they liked it, major isn't here but he did as well
16:48:35 <odyssey4me> what is the purpose of it, considering that the returned data is unordered
16:48:48 <BjoernT> how do you separate from a comment or deactivated tokens which have been added for testing ?
16:48:51 <odyssey4me> ie a comment about a line below will no longer be above the line
16:49:32 <odyssey4me> this only ever matters when the pwgen is run, which I expect is not often
16:49:51 <odyssey4me> so I really just don't see the point... this just seems like dev work done to solve no problem
16:50:06 <odyssey4me> so, personally, I'd like to understand the problem this is trying to solve
16:50:40 <palendae> Yeah, I can get why someone might like to keep comments associated with the given line, but this doesn't appear to do that
16:50:54 <odyssey4me> ^ that
16:51:13 <palendae> From just glancing over the code, it drops the comments at the top of the file
16:51:16 <odyssey4me> also, I don't see why someone would want to run pwgen more than once
16:51:37 <odyssey4me> if it is, there's always a backup
16:51:50 <odyssey4me> if anything, I'd say there may be value in keeping datestamped backups
16:52:00 <prometheanfire> it keeps a backup of the file it overwrites?
16:52:02 <cloudnull> thats already there
16:52:06 <prometheanfire> that'd be better
16:52:08 <odyssey4me> yes it does
16:52:13 <prometheanfire> ok
16:52:14 <palendae> Yeah, we already have backed up copies of files
16:52:32 <cloudnull> anytime there is a change in the file it writes the old one to a backup
16:52:48 <prometheanfire> abandoned
16:53:03 <odyssey4me> so it only keeps one tarballed backup - I can see value in perhaps having 5 backups, datetimestamped or something
16:53:12 <palendae> I'd be interested to see if there's a change that associates a line with it's comments, but the way the yaml dump works would make that difficult
16:53:26 <palendae> its*
16:53:27 <odyssey4me> yeah, hardly worth the effort
16:53:40 <prometheanfire> close associated bug as well?
16:53:43 <odyssey4me> I think the right approach for config storage anyway is to use something like git to keep history
16:53:54 <odyssey4me> prometheanfire yep, please
16:55:18 <odyssey4me> anything else - we have 5 mins?
16:57:43 <odyssey4me> alright, that seems to be it
16:57:50 <odyssey4me> thank you everyone!
16:57:55 <odyssey4me> #endmeeting