15:00:11 <gundalow> #startmeeting Public Core Meeting
15:00:11 <zodbot> Meeting started Thu Jan  5 15:00:11 2017 UTC.  The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:11 <zodbot> The meeting name has been set to 'public_core_meeting'
15:00:18 * mattclay waves
15:00:31 <gundalow> #chair abadger1999 allanice001 jimi|ansible jtanner mattclay nitzmahone
15:00:31 <zodbot> Current chairs: abadger1999 allanice001 gundalow jimi|ansible jtanner mattclay nitzmahone
15:00:42 <allanice001> holla
15:00:46 <nitzmahone> Yo
15:01:00 <gundalow> #info Agenda https://github.com/ansible/community/issues/148
15:01:56 <gundalow> Gona start from the end and work up
15:02:06 <gundalow> #topic When should we start removing submodule commands from various docs/scripts?
15:02:07 <ryansb> Ok, guess that's me
15:02:17 <gundalow> #chair ryansb
15:02:17 <zodbot> Current chairs: abadger1999 allanice001 gundalow jimi|ansible jtanner mattclay nitzmahone ryansb
15:02:39 <jtanner> why couldn't submodule refs be removed right now?
15:02:58 <ryansb> The `hacking` scripts use --recursive clones, and submodule update. It doesn't hurt anything, but I don't know if people always use the checked out versions of those scripts
15:03:16 <ryansb> like, do people use a newer hacking script located somewhere in their env to work on older ansible versions?
15:03:18 <jtanner> i've always run hacking from the checkout
15:03:20 <gundalow> It can only be removed from scripts that are versioned. I'm not sure if their are any parts of releasing/hacking that are always from from `devel`
15:03:50 <jtanner> i don't understand what that means
15:03:54 <gundalow> Do any of these instances give out warnings/errors?
15:03:57 <ryansb> If not, we can remove it from all of those (including the pkgbuild for arch) and assume people use the checked out versions
15:04:46 <gundalow> jtanner: For example. Are the build & release scripts always run from devel, rather than from stable-x.y
15:05:03 <jtanner> no
15:05:10 <ryansb> gundalow: for the stable releases we'd use the version on that branch
15:05:13 <jtanner> releases come from stable branches
15:05:36 <ryansb> so we wouldn't backport the "remove submodule command" changes to the pre-2.2 stable
15:05:42 <ryansb> err, 2.2 and older
15:09:18 <gundalow> hum, I thought packaging/release/release.yml always got run from devel, though I may be miss remembering. Would need jimi|ansible to confirm
15:09:30 <jimi|ansible> it does get run from devel only
15:10:19 <jimi|ansible> however, because it checks things out it still needs the submodule stuff in the release.yml
15:10:46 <jimi|ansible> i mean, it clones the repo clean and then checks out the stable branch, which still uses submodules
15:10:50 <jimi|ansible> make sense?
15:11:21 <ryansb> Ah, ok, so can't touch the release script
15:11:34 <jtanner> oh ...
15:11:44 <jtanner> it doesn't build from the current checkout?
15:11:53 <jtanner> how does one test a patch to the build scripts?
15:12:36 <gundalow> to avoid local changes releases are generally always made from a fresh & dedicated checkout
15:16:24 <allanice001> so, for 2.3, removing submodule from release script  would be the final step?
15:17:53 <allanice001> but would most likely break backport for 2.2 and older
15:18:31 <ryansb> ok, so I think that's resolved. Don't touch submodule refs in release scripts, but other places are fine
15:18:40 <ryansb> sound good?
15:18:44 <jtanner> shipit
15:18:50 <allanice001> +1
15:19:13 <ryansb> #action ryansb remove outdated submodule refs from error messages and non-release scripts
15:24:38 <gundalow> cool, next topic then?
15:24:46 <gundalow> #topic ansible/ansible#19500 Update assemble to allow alternate source of files
15:25:00 <gundalow> #info https://github.com/ansible/ansible/pull/19500
15:25:34 <gundalow> Needs some other eyes on it
15:25:44 <kennc> looks good to me :)
15:25:48 <jtanner> who is the maintainer?
15:26:05 * gundalow has to step out for 5 mins
15:26:23 <jtanner> has none .. =/
15:26:34 <jtanner> supported by core though
15:28:23 <bcoca> -1 on that, i dont think that feature makes much sense
15:28:31 <kennc> why?
15:28:42 <kennc> I think I make a clear case for it
15:28:49 <kennc> provide testing on it?
15:29:15 <bcoca> passing a list of files vs having the files in a directory
15:29:27 <kennc> why does ordering in alphabetical make sense?
15:29:28 <bcoca> a directory is a list of files
15:29:36 <bcoca> ordering is filesystem based
15:29:45 <bcoca> if you want ordering make a sorting feature, not a list
15:29:58 <bcoca> this is alternate source, not ordering
15:30:11 <kennc> If you look at my example, I think it will make sense
15:30:47 <bcoca> i understand what you are trying to do, i just don't think it is a good feature
15:30:58 <kennc> alright
15:31:13 <bcoca> current ordering depends on filesystem (most common ones use alphabetical, but it can also be different)
15:31:24 <kennc> can't argue with people's opinions
15:31:40 <kennc> only can state it has come up several times
15:32:11 <ryansb> kennc: would having a param like "sort_method" or similar resolve your problem?
15:32:11 <bcoca> sorting has, sourcing has not
15:32:16 <kennc> no
15:32:34 <kennc> that was to ryansb
15:32:36 <bcoca> and mostly as a question, not as  reques
15:33:00 <kennc> sorry, should have clarfied
15:33:06 <kennc> it has come up several times to me
15:33:35 <jtanner> looks as though the pr adds the ability to span across multiple directories/files ... so doesn't appear a sort_method would help
15:33:39 <bcoca> understood, but we need to look at the big picture, i dont see this as useful to the general user
15:33:45 <mattclay> The first example could be handled by using a single directory with symlinks to the various files. The second example by prefixing the source file names with numbers for ordering. That works w/o making changes to assemble.
15:33:59 <bcoca> jtanner: its not a sort, its a 'list of files not from a directory'
15:34:06 <ryansb> Or using a jinja2 template that uses file lookups
15:34:15 <jtanner> just responding to ryansb about sort_method
15:34:27 <kennc> doesn't really scale the same way doing symlink
15:34:31 <bcoca> yes, many ways to get around it w/o need of option
15:35:12 <bcoca> im not against a pure 'sort' option,  this 'alternate source' seems too niche
15:35:33 <ryansb> alternately: having this option doesn't impede regular users either
15:35:49 <kennc> /var/config/{{ inventory_hostname }}/route
15:35:55 <kennc> doesn't scale with symlinks
15:35:58 <bcoca> i think it will confuse them
15:36:05 <kennc> who is them?
15:36:10 <bcoca> users
15:36:22 <bcoca> as it works in very differnt manner than the directory
15:36:37 <jtanner> we can't know the psychology of everyone ... i'm also not clear as to why core owns this module
15:37:30 <bcoca> like template it is a basic way of managing file configurations
15:37:45 <bcoca> not that this cound not be done via template and jinja2 includes
15:38:11 <jtanner> so it simplifies a common pattern
15:38:12 <bcoca> ^ kennc i would actualy point you to that if you want to supply an ordered list to assemble
15:38:51 <jtanner> if making unncessary symlinks to span across multiple dirs is another common pattern people use for the module, i don't see why we can't allow someone to abstract that
15:38:54 <bcoca> well, the big difference is that tempalte always operates on controller, assemble was initially created to operate ONLY on target, local operation was added later on
15:39:15 <bcoca> ^ i think they overlap too much as it is
15:40:04 <kennc> the idea is to have config sections with jinja, output pieces and then assemble based on logical ordering
15:40:43 <bcoca> if you are already using jinja, why not assemble there? you can already control the exact list/order there
15:40:44 <kennc> bcoca: if you are saying one large jinja, I don't think that will work
15:40:54 <bcoca> and again, this feature does not add ordering, just an alternate source list
15:41:29 <bcoca> kennc: not sure what you mean by that, but assemble cannot do anything template cannot
15:41:30 <kennc> a thought by definition a list is ordered
15:41:37 <bcoca> ^ except 'remote assemble'
15:42:11 <allanice001> jinja templates can be easily extended / included in parent and child templates
15:42:12 <bcoca> kennc: that is a consequence of the feature, otherwise it would just be a sort
15:43:29 <alikins> I have no strong opinions on the feature, but the code looks reasonable. And it has tests!
15:43:31 <bcoca> the feature as added is not an 'alternate ordering' its an 'alternate source', order in both cases depends on source ordering
15:46:15 <kennc> all I can say is it provides a function that is more logical than 001-file, 002-file, etc.. It has already been coded, and there is tests.
15:46:38 <kennc> I understand you have to look at it from a different angle
15:47:02 <kennc> So I won't press any further, just encourage other's to comment on it, if they see the need
15:47:32 <bcoca> i would like to avoid clutter in core modules, specially of features that don't seem that useful or are easily available in other ways
15:47:58 <bcoca> my main problem is that you want a sort, but are implementing a alternate sourcing as a way of controlling sort order
15:48:02 <kennc> we have different opinions on easy :)
15:48:10 <bcoca> which makes me think this is not the best way to do what you want
15:48:36 <allanice001> kennc: with a jinja template, you can {% include ‘z’ %}.. {%include ‘a’ %} in any order you want / need
15:48:47 <bcoca> kennc: that is always true, easy is subjective, let me say 'simple' which is more objective
15:49:37 <bcoca> both file naming (prefix/symlink) and template includes are simple alternatives
15:51:06 <kennc> I only ask you leave comments to reason for closing so people can chime in.
15:52:02 <bcoca> i have not closed it, i'm still waiting for other opinions
15:52:16 <bcoca> there might be a reason i'm missing or somethign that invalidates my argument
15:52:26 <bcoca> otherwise i would have closed the ticket weeks ago
15:53:03 <kennc> sorry, if it is closed
15:53:25 <bcoca> most of what i've heard from others is 'i dont mind it'
15:54:35 <alikins> having a mechanism to enforce an ordering seems useful
15:55:27 <alikins> especially if the fragments can't be renamed for some reason
15:56:30 <bcoca> i dont disagree on ordering, its making alternate sourcing as a way to achieve it
15:56:42 <bcoca> seems like a backwards way to do it
15:57:22 <bcoca> and as allanice001showed, the current implementation is trivial to create via a tempalte
16:00:12 <alikins> puppets concat allows providing a rank ('order') for fragments, but that would need new args as well
16:00:50 <alikins> but should probably get to other things on the agenda, if there is anything else
16:01:08 <bcoca> again, i would be fine if the feature was an actual sort
16:01:32 <bcoca> but it is not, the sorting is an effect of passing a list of files as a source
16:01:40 <mattclay> If the needed ordering is arbitrary (instead of just a different sort method), I don't think there's another way to do it, except to provide an alternate source which is already manually sorted, assuming you want to use assemble.
16:01:42 <kennc> let's take that out of the talk for here
16:01:52 <kennc> doing a sort does not help this use case
16:04:26 <bcoca> no, but the other 2 alternatives provided do, w/o the need of new code
16:07:58 <allanice001> if going the jinja route, you can acheive a crapload with exceptions and filters
16:08:12 <allanice001> http://jinja.pocoo.org/docs/dev/api/#exceptions
16:08:50 <gundalow> OK, that's 30 minutes on this topic.
16:09:02 <gundalow> What are the next steps
16:10:21 <gundalow> We can continue for another 50 minutes (till the next meeting) Just want to make sure we are progressing :)
16:10:41 <allanice001> might need to drag the laptop to dinner then :D
16:11:10 <kennc> I don't have anything else to add
16:11:54 <allanice001> personally, i’m with bcoca on this, alternatives exists without additional code requirements
16:12:48 <bcoca> for me an ordered list of files is the same as a directory with symlinks, i dont see this as adding much featurewise for the cost of extra code maintenance
16:13:40 <bcoca> teh argument about file names changing ... affects both lists
16:14:33 <bcoca> im reticent to reject it, but i'm still waiting for a compelling use case
16:21:05 <allanice001> how many would use this, where either of the alternatives presented are already existing in their current usages?
16:22:22 <kennc> not really sure I understand. Why have the module at all? Just user jinja and sort the directory alphabetically?
16:22:36 <kennc> allanice001: ^^
16:22:42 <allanice001> right
16:22:46 <bcoca> kennc: as i said, module initially was made to operate remotely, which templates cannot do
16:22:54 <kennc> again, I don't want to derail
16:23:14 <bcoca> and i agree, the local feature is an overlap, which i disagree with
16:24:12 <allanice001> also, kennc if im currently using jinja / alpha sort of directory, why would i shift to this feature
16:24:40 <kennc> we are going in circles :)
16:25:02 <kennc> seriously I don't want to derail this meeting, more than  I already have
16:25:23 <kennc> To me the argument holds up for both, or none.
16:26:15 <kennc> I do not foresee changing your minds, I think I have a use case that is compelling, you don't.
16:26:19 <kennc> I'm ok with that
16:27:01 <gundalow> kennc: Don't worry about it. We get stuck on one topic fairly often
16:27:19 * abadger1999 wakes up and looks in
16:27:51 <allanice001> kennc, dont get me wrong, i get your point too.
16:27:59 <kennc> I know you do :)
16:28:18 <kennc> and I understand you have to look at a larger picture
16:29:39 <gundalow> I'm gona call the end of the meeting in 15 minutes. I know we have a few other items on the agenda from mattclay, however we've chatted and we will push them to the next meeting. Does anyone else have anything for today?
16:29:55 <gundalow> If not we've got 15 minutes to continue on assemble & multiple sources
16:30:36 <allanice001> gundalow: i got nothing
16:32:02 <bcoca> kennc: i have same argument for both, we have plenty of features in existing code that i disagree with
16:32:18 <bcoca> *cough* copy content *cough*
16:43:47 <gundalow> OK
16:43:49 <gundalow> Gona call it
16:43:58 <gundalow> Thanks for your time everyone
16:44:25 <gundalow> As always add discussion points onto https://github.com/ansible/community/issues/148
16:44:52 <gundalow> PR for removing/updating mentions of git submodule is out for review https://github.com/ansible/ansible/pull/19941
16:44:55 <gundalow> #endmeeting