19:00:24 #startmeeting ansible core irc public meeting 19:00:24 Meeting started Tue Aug 14 19:00:24 2018 UTC. 19:00:24 This meeting is logged and archived in a public location. 19:00:24 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:24 The meeting name has been set to 'ansible_core_irc_public_meeting' 19:00:37 o/ 19:00:53 #topic flip invalid_task-attribute_failed to true by default 19:00:55 .hello2 19:00:56 sivel: sivel 'Matt Martz' 19:00:58 o/ 19:01:01 * shertel waves 19:01:29 * gundalow waves 19:01:31 This topic is me, but I'll wait a few moments 19:01:33 @sivel fine with me as long as msg adds that you can toggle to warning 19:02:22 basically, current funcitonality, is when applying a task arg, that is invalid. Say "delegat_to", you get a warning, instead of an error 19:02:29 the toggle adds the ability to make it an error 19:02:44 I'm thinking it should probably be an error to begin with, toggled to be a warning 19:02:55 +1 19:02:59 toggle is being added in 2.7 19:03:08 we had it as error originally but too many people complained, its been a warning long enough, so we should change it 19:03:13 so this is all new for that release, as far as changing behavior 19:03:30 .hello2 19:03:31 maxamillion: maxamillion 'Adam Miller' 19:03:34 so, anyone against flipping it to be an error? 19:03:38 Bogus module args are a failure, as are lots of other things, dunno why we should treat playbook grammar more lax 19:03:39 by default 19:03:49 +1 19:04:22 * bcoca still has proposal for warning/error on keywords that are ignored by some actions 19:04:22 cool, we have at least +4, and no one against it 19:04:30 who is against? 19:04:37 no one 19:04:44 or they haven't spoken up 19:04:48 +1 19:05:07 cool, then I'll info it 19:05:29 #info sivel will create a PR to swap invalid_task-attribute_failed to true by default, and indicate in the error it can be toggled to a warning 19:05:55 #topic https://github.com/ansible/community/issues/329 19:05:59 So for this like this: Clear docs (ensure all our examples are updated), maybe we need a way of informing people outside of Core of language changes, etc 19:06:57 ^ i think the strategy is good, just need to settle on name, i would hate we dont merge this cause of bikeshed lock 19:07:57 darn ...linkedwrongthing ... 19:07:57 What are we pointing at? I'm just seeing recursive links to the agenda 19:08:08 Whoa, I'm confused. about #329 19:08:11 the 'currently' streamlined strategy 19:08:14 looking for pr 19:08:32 yeah 19:08:33 https://github.com/ansible/ansible/pull/39602 19:08:50 #topic https://github.com/ansible/community/issues/329 19:08:53 dammit ...again 19:09:04 #topic https://github.com/ansible/ansible/pull/39602 19:09:12 sorry ... rampant dislexia today ... 19:09:56 fwiw I like what's mentioned in this comment ... alias current free to free_task_first and make the new one free_host_first https://github.com/ansible/ansible/pull/39602#issuecomment-412346400 19:10:16 I like that a lot better 19:10:18 it's a little verbose, but it's meaningful at face value 19:10:18 but we need to keep 'free' for backwards compat, even if we deprecate the name 19:10:23 yep 19:10:29 absolutely 19:10:30 its really host_stick vs nowait 19:10:35 host_sticky 19:10:49 free_task_first is not really good name for current free either 19:11:09 it will jumpt ot next host for current task, it just avoids going to next task if any hosts are still doing previous 19:11:19 linear = lockstep, free = nowait 19:11:31 yeah, that's fair 19:11:44 this new one is really 'fork_is_host_sticky' 19:11:52 +1 shipit 19:11:58 :) 19:12:03 we rename all? 19:12:38 well, can we agree for name of new one? we can tackle renaming others as diff task 19:12:40 eh, on one hand it makes sense to for the sake of clarity but on the other hand, it's not necessary 19:12:48 yeah 19:13:26 I'm fine with "streamlined" if people want to stick to that ... I think it's as meaningful as "free" at face value and as long as it's well defined in the docs, then whatever 19:14:20 * abadger1999 likes the proposed name/alias 19:14:22 but I think "batch" or "free_host_first" is probably better 19:14:29 I don't think streamlined is particularly decscriptive 19:14:34 nitzmahone: agreed 19:14:39 * abadger1999 not a fan of streamlined 19:14:42 nitzmahone: but neither are any of the others 19:14:43 so we have a)streamlined b)batch c) incumbent d)atomic .. any other names? 19:14:48 about as useful as fast_in_some_cases" 19:14:57 fork_host_affinity 19:14:59 @bcoca bequeath? 19:15:08 sivel: oooo, I do like that 19:15:19 ryansb: that worked for includes , but not strategy, but ++ for slipping it in 19:15:19 *shrug* I've mentioned several times I think the best name should indicate that the fork has an affinity for an individual host 19:15:21 free_task_first / free_host_first 19:15:30 abadger1999: +1 19:15:34 having to change free.py to implement 'streamlined' is a little weird, especially when it special cases streamline. maybe make get_workers_free() and post_step() in free.py and override? 19:15:38 its free host, not task 19:15:55 suggest host_afinity 19:16:04 alikins: how would user choose behaviour? 19:16:08 host_afinity 19:16:14 ^ f) 19:16:15 I think he's just talking impl 19:16:17 that was the last one in the ticket and it seemed like a winner to me. 19:16:21 (IIUC) 19:16:26 but tbh I'm not sure i have understood it 19:16:33 host_affinity is not terrible 19:16:40 bcoca: huh? override in the streamline.StrategyModule class 19:16:52 alikins: but still a separate plugin? 19:16:58 yeah, host_affinity is pretty good and it makes it shorter 19:17:15 ok, so host_affinity is in the lead 19:17:21 the current "free" could become task_affinity and aliased 19:17:29 +1 host_affinity 19:17:30 not really task_Affinity 19:17:40 Not sure task_affinity is much clearer than free 19:17:42 as it still does hosts > tasks, it just doesn wait for all hosts to finish task 19:17:47 clearer, but wrong 19:17:48 it also removes the "fork" from the name, because it might be threads in the future 19:17:50 afinity itself isn't that clear. 19:18:01 should look up synonyms to that word. 19:18:19 host_pegged 19:18:39 pegged, pinned, [...]? 19:18:51 affection, closeness, rapport, leaning, fondness, sympathy 19:18:53 favour_host ... 19:18:56 host_sympathy ... 19:19:03 host_fondness 19:19:08 a++ 19:19:08 ryansb: Karma for sagy changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:19:48 I like pinned 19:19:57 host_pinned if we're anti-affinity 19:19:59 attraction bond 19:20:05 covalent? 19:20:07 hostbonded 19:20:09 heh 19:20:14 host_simpatico 19:20:23 bcoca: that's going to get us in trouble with networking folks ;) 19:20:43 partiality yerning 19:20:46 there are more bonds in the world than interface bonds 19:20:50 host_pinned +1, host_affinity doesn't say much to me (non-native speaker) 19:21:04 +1 for host_affinity 19:21:21 +1.1 for host_pinned, +1 for host_affinity 19:21:30 host_pinned 2, host_affinity 1, keep voting 19:21:41 +1 host_affinity 19:21:44 2/2 19:21:46 host_pinned +1 19:21:50 3/2 19:22:08 anyone else? 19:22:14 0 from me 19:22:15 host_pinned +1 19:22:18 4/2 19:22:21 pinned in teh lead 19:22:30 I'm torn :/ 19:22:37 closing vote in 30s, 19:22:39 host_affinity +1 19:22:49 4/3 19:23:01 "CPU affinity" is a term, though I think maybe "pinning" may be easier to understand 19:23:02 also, I'd be okay if host_affinity comes out as winner too... it's not terrible. 19:23:12 host_pinned it is 19:23:29 yeah, that was a close second for me 19:23:29 idc as long as we merge the feature and the name is not horrible, i can live with either 19:23:33 +1 19:23:42 k, alikins you want to make implenetation comment on ticket? 19:23:50 i'll break news on 'we got a name!' 19:23:51 I'm good with host_pinned 19:23:54 bcoca: :D 19:24:09 #topic https://github.com/ansible/ansible/pull/43621 19:25:08 yo 19:25:38 I don't think there's anything controversial here, now... it would be nice to have a thorough review but the dnf maintainer probably is no longer around so.... 19:25:50 im fine with exception, we've made em before, but we should make clear rules instead of case by case 19:26:04 If we can get the licensing straightened out quickly, I'm kay with it. 19:26:16 but then i would ask we do same for apt 19:26:17 so we have a situation where I've created a module_util that's derivative work of the yum module, which is GPLv3 and we're unable to get sign off from some of the maintainers because of $reasons ... I was hoping to have a public discussion about the situation and request an exception 19:26:31 I think the only exception we've made is for facts which predated a lot. 19:26:41 *but* we've had a lot of things get in by accident. 19:27:04 I don't think exceptions are good. 19:27:13 But a guideline would be good. 19:27:42 Do we need CI enforced module_utils (with exception list) to stop more being added once we have confirmred that BSD should still be default? 19:27:43 we had more initially but we've migrated many chunks 19:27:53 gundalow++ 19:28:27 I had a proposal of: "Something like module_utils that are for a specific, small set of modules are allowed to be under gplv3+ instead of BSD. module-utils that are generic in nature (could be used with modules from more than one vendor or project) must be BSD. If there's doubt as to which category a module_util falls into, have it discussed by the core team." 19:28:44 the thing I think is unique in this instance is that the original yum author is deceased (may he rest in peace) so I think it leads to a weird legal space attempting to re-license 19:29:03 abadger1999: I think that's good 19:29:09 maxamillion: We make that RH legals problem to solve 19:29:47 abadger1999: that causes issues with the original intent though potentially. The idea was that anyone could extend from any of the module_utils without having to bring along the GPL license 19:29:49 Using the person abadger1999 or I mentioned internally 19:29:51 gundalow: fair, but then this has to wait for months for them to sort it out and I'd really like to make the 2.7 deadline 19:30:07 examples that i think should fall under that would be , this module_utils code, the apt module_utils code we discussed a few weeks ago, module_utils that are specific to a vendor's api for talking to their hardware/service. 19:31:23 abadger1999: +1 19:31:24 examples i don't think should fall under this: fetching of files from the interner (which is one part of this module_utils PR that would need to be relicensed), a retries decorator (Which we've been trying to get relicensed but will probably have to rop and relicense from scratch). 19:31:42 abadger1999: I think it makes sense and as long as we have good examples to help people sort it out, it's good 19:31:49 anything that ends up in the new common/ directory, things in network/common directory. 19:31:53 abadger1999: which retry decorator? iirc i wrote the original 19:32:11 bcoca: yeah... you wrote it other people contributed. we've not gotten sign off from everyone. 19:32:33 bcoca: we could go back to your original code and you put it under the bsd andthen other people fix it again. 19:33:07 was mostly expanded to specific clouds and in aws case, teh api changed on a few things 19:33:23 but i have not looked at it in a while , might not recognize it as this point 19:33:40 don't look otherwise you might not be able to participate in a reimplementation ;-) 19:33:45 ha 19:34:22 @sivel yep. that is the problem. 19:34:51 oh. :/ yeah I've looked at that. 19:35:05 So in general, I am less flexible than saying, a small set of modules...I'd say, BSD unless you convince us otherwise 19:35:15 sivel: but we're having more and more difficulty here... are we willing to decide that the scales are different now and we should change? 19:35:18 bcoca: FYI I added Contributors Summit to the agenda, would like to chat a bit about that at the end if there is time 19:35:28 sivel: I dislike that because it sets up up for a double standard. 19:35:30 gundalow: saw it 19:35:52 bcoca: :) 19:35:55 sivel: it seems arbitrary, we should at least lay down some rules on when we would consider gpl 19:36:01 this yumdnf thing can use gpl because we need it but this apt thing or cisco thing or etc can't because.... well, we said no. 19:36:16 sure, but considering, should not be the same as agreeing to it 19:36:20 there should be something non-arbitrary 19:36:28 i think that a) very specific usage b) already depends on GPL libs 19:36:51 in this case, is an alternative implmentation of the module_utils a possibility? 19:36:54 and for specific usage a) existing api for specific appliance/webservice 19:37:13 i.e ok for slack interface, not ok for 'generic chat interface' 19:37:15 sure, I just want to point out, that our guidelines are a means to determine feasability to use GPL, not that we will blindly accept the code as GPL it it meets the requirements arbitrarily 19:37:27 I guess someone who hasn't looked would have to implement it 19:37:29 like, I'm lazy and don't want to ask about relicensing 19:37:43 jhawkesworth_: in some cases, yes, but hard for some of the simpler code to not look the same, in the case of apt its also the library imported 19:37:45 Anything in the guidelines should be super specific 19:38:03 I don't think that we should turn down licensing a thing as GPL if it meets the criteria... but we can decide whether it meets the criteria or not. 19:38:13 +1 19:38:18 1) There is no potential way to have this relicensed from GPLv3 to BSD 19:38:22 I think that is about it 19:38:34 can add sub bullets about the meaning 19:38:50 +1 19:38:50 a) Death of an author 19:38:53 (for instance, a function named fetch_rpm_from_url may look like it's specific, but after reviewing it we might say "this code actually is fetch_file_from_url() so it isn't specific to rpm's at all" 19:38:58 the thing, both yum and apt are used in many distros ... so we are really stretching 'narrow' in that case, but they are used by very few modules, which does apply 19:39:28 for this code, we'd have to send it to red hat legal, then. 19:39:29 ^ and that, not all code that 'is specific' needs to be 19:39:39 as red hat legal could well have rights to relicense it. 19:39:52 was andrew RH employee at time? 19:40:11 who is andrew? 19:40:21 * bcoca might have name wrong ... 19:40:26 (maybe we're suddenly talking about different code?) 19:41:01 no, meant seth ... no clue why i was thinking 'andrew' 19:41:39 yeah. svidal was employed by red hat the whole time ansible was being created. 19:41:47 yeah 19:41:58 so unless his contract stated it explicitly, its probably doable .. but it will take time 19:42:04 I'm alright throwing to RH Legal if we can get a decision back *soon* 19:42:04 yep. 19:42:12 can/should we include as GPL until the lawyers resolve it? 19:42:16 and we don't know how long it will take. 19:42:43 I don't think we should knowingly add more gpl module_utils unless we've decided to change our rules. 19:42:45 problem is subsequent contributions, must be monitored and always ask for relicence to bsd permissions 19:43:19 well, the rule is there to allow 3rd parties to share/ship modules and rely on module_utils w/o having to reimplement 19:43:28 fwiw, in my view, this would be a time I would say that GPL is allowed. I indicated that in a disucssion earlier, saying I didn't believe relicensing would be feasible 19:43:37 if we can do 'narrow' cases like this, im fine, dont see many modules reusing apt/yum internals 19:43:47 I think relicensing probably is feasible. 19:44:01 But it's not something we can do, it's something that red hat would have to look into. 19:44:03 im ok with allowing gpl, but only on narrow focused shared code 19:44:04 feasible in the necessary time frame 19:44:15 that seems problematic. 19:44:23 its problematic either way 19:44:27 agreed 19:44:49 we either allow it or deny and make the code/fixes wait till lawyers get done 19:44:51 and really, the code as it stands right now is very specific to the use case, but I do agree with the concern of "what if that module_util grows over time" 19:45:04 $vendor hasa set of modules they want to get into 2.7 but they can't get the module_utils relicensed before freeze. 19:45:09 if we allow, we have 2 options, plain allow gpl, allow 'for now' with views to move to bsd once laywers clear 19:45:24 bcoca: +1 19:45:30 that should then be allowed in under the same guidelines of "feasible in the necessary timeframe" 19:45:37 abadger1999: im fine if module_utils is just for specific vendor api/appliance 19:45:39 I'm happy to relicense to BSD once RH Lawyers sign off 19:45:51 bcoca: I am too.. .thus, my proposal. 19:46:06 maxamillion: the problem is that any contribution on the 'currently gpl' would have to require they singing off on future bsd relicence 19:46:14 but that's different than saying it's allowed because it's infeasible to relicense in $timeframe. 19:46:15 ^ need to be very good at keeping tha tin mind 19:46:25 bcoca: I don't see how that's any different than right now 19:46:44 right now we are already in trouble, doesnt mean we should keep adding logs to the fire 19:46:46 bcoca: I'm the "original author" of the module_util but it's derivative work 19:47:10 so im ok with all 3 scenarios, but would prefer to include the code vs not include 19:47:16 I guess I just don't understand how it's different if we do it now or later from an inconvenience standpoint 19:47:24 +1 19:47:31 a) forbid non gpl, b) allow gpl with narrow focus c) temp allow gpl with views of relicensing 19:47:41 b) is my preference, but i can live with c and regret a 19:47:43 I dislike the idea of legal blocking development if we have an acceptable path forward from the legal perspective 19:47:49 agreed 19:47:59 which is why a) is my least fav 19:48:05 anyhow, I'm +1 on hcanging our guidelines, or +1 on continuing to say no to gpl code in module_utils. 19:48:12 yeah, I like B or C ... which ever the group prefers 19:48:23 I'm not okay on making an exception for this because it's convenient for us. 19:48:24 so b) seems only common one to all? 19:48:36 abadger1999: agreed, it has to be a general rule 19:48:47 o/ 19:48:53 jtanner: inputs? 19:49:00 bbias 19:49:10 anyone else? 19:49:36 so b wins, abadger1999 want to define the 'narrow focus' rules? 19:49:53 we should probably vote on the narrow focus rules. 19:50:18 * abadger1999 wordsmiths what he said earlier 19:50:19 im ok on that, want to propose them? 19:50:22 c seems like a management pain 19:50:33 too late for a i think 19:50:36 c is a mangement pain, but its also a compromise 19:50:45 well, a) is 'new' 19:50:55 not old, that we should be working on changing/replacing 19:51:14 the few we've relicensed seem to be a pita 19:51:15 module_utils that are for a small set of modules for a specific vendor's hardware or service are allowed to be under gplv3+ instead of BSD. module-utils that are generic in nature (could be used with modules from more than one vendor or project) must be BSD. If there's doubt as to which category a module_util falls into, the Ansible Core Team will decide.. 19:51:33 +1 19:52:22 are we able to make the call on gpl vs bsd in each case or do we need to involve legal? 19:52:46 +1 on that 'ruleset' 19:53:19 I can't say for sure but I think we will be able to make the call in each case... legal probably would be happiest if we just made everything gplv3+. 19:53:21 jtanner: since we're not relicensing code, I don't think we would need to involve legal 19:53:36 +1 -if- we have the freedom/capability to make the call in each case without too much back and forth with lawyers 19:53:38 yeah, whole point is avoid to wait for legal for relicense 19:53:42 but we can give them a heads up about the guideline change and see what they say 19:54:40 +1 for this guideline from me. 19:54:49 ok, so going to call vote on ^ @abadger1999 rules for allowing gpl in module_utils 19:54:52 +1 from me also 19:54:54 no wait 19:55:03 i want jimi and nitz to vote one way or the other 19:55:11 I'm +1 for that 19:55:18 jimi|ansible ^ 19:55:18 jimi|ansible: what say you 19:55:22 reading... 19:55:32 [15:51] module_utils that are for a small set of modules for a specific vendor's hardware or service are allowed to be under gplv3+ instead of BSD. module-utils that are generic in nature (could be used with modules from more than one vendor or project) must be BSD. If there's doubt as to which category a module_util falls into, the Ansible Core Team will decide.. 19:55:34 +1 19:55:37 ^ voting on that 19:55:38 works for me 19:55:41 \o/ 19:55:45 ok, overwhelming majority, passed 19:55:49 where in the docs should we put that? 19:55:56 we already have bit on licensing 19:56:03 we also have comments in module_utils iirc 19:56:07 i believe that's always been the unofficial stance, so good to make it official 19:56:11 aside from docs, iirc we had some sanity checks enforcing bsd 19:56:15 https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_checklist.html ? 19:56:34 #topic contributor summit 19:56:36 jtanner: I think you're right 19:56:38 contributor guidelines I think. which will be good because sivel pointed out early i nthe day that the BSD rationale isn't mentioned there either. 19:56:41 Ignore the "where" acozine is working on moving those docs around 19:56:52 abadger1999: alright, I'll follow up off-meeting 19:57:02 I have a thing that needs a vote from last meeting too. 19:57:16 gundalow: ^ contributor summit is yours to announce :-) 19:57:20 Thanks 19:57:28 voting on contrib summit? 19:57:33 * jtanner is lost 19:57:42 jtanner: disjoint topics 19:57:58 jtanner: abadger1999 needs a vote on something from last week *AND* gundalow is going to talk about contrib summit 19:57:59 Just a reminder to add stuff to https://github.com/ansible/community/blob/docs-network-roles-process/group-network/roles_development_process.rst#new-role 19:58:09 Bah, not that 19:58:11 https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_in_groups.html 19:58:16 To https://etherpad.openstack.org/p/ansible-summit-october-2018 19:58:21 ^ has bsd 19:58:39 gundalow++ 19:58:40 maxamillion: Karma for gundalow changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:58:51 And if you are in a working group, *please* encourage people in that group to add ideas 19:59:23 is that "+1+1+1" or "+N" ? 20:00:06 anything else? 20:00:06 Agenda is a little sparse at the moment, It's only 6 weeks weeks till Contributors Summit/AnsibleFest 20:00:09 jtanner: ? 20:00:21 doing a +1 in the etherpad 20:00:21 nothing else from me, over ot abadger1999 if he had something to vote on 20:00:32 jtanner: `+1+1+1` is fine 20:00:46 If Etherpad is working we should see who's voted on things 20:01:38 So last week we talked about having a plan to add a toggle to file to deprecate how state=file handles nonexistent files.. The toggle would be added in 2.8 with the same default as now (do not create a nonexistent file). In 4 releases, we'd change the default to create the nonexistent file. 20:01:47 #topicfoo? 20:01:50 #open floor 20:01:55 #topic open floor 20:02:11 Current voting was at +2 (abadger sivel) to do that, -1 (bcoca) against. 20:02:27 iirc sivel was on the part of touch and rest having diff defaults 20:02:33 is that encapsulated in a proposal or pr ? 20:02:33 but @sivel knows exactly 20:02:52 catching back up 20:02:54 one sec 20:02:54 -1 jsut from user having to wait 5 versions to get the feature 20:03:16 i still prefer having the new _time options default == None, which behaves differnetly for touch 20:03:19 It stemmed from the fact that the file module also has a state=touch argument which was added because state=file does not create nonexistent files. 20:03:23 since touch already behaves differntly 20:03:39 state=touch ... terrible. 20:03:40 but state=touch is not idempotent because it sets the timestamp to now. 20:04:07 yes, its terrible and non idempotent, but i dont except touch to be idempotent, i dont think most users do either 20:04:25 users expect touch to do something different 20:04:33 should be "touched=(True|False)" imo and be an alternate for state arg 20:04:35 there' s a pr to add specifying timestamps (good, that part is approved) but the question there was whether to change the default so that it preserved the current timestamp (making it idempotent byt default) 20:04:46 jtanner: yes, but shipp sailed and deprecation is long 20:04:59 i know ... i rant pointlessly 20:04:59 jtanner: or a touch module even, since file already has 'non states' as state= 20:05:05 I was saying that touch, by default should still modify the timestamp, unless a timestamp was explicitly provided 20:05:20 to act just like the touch cli 20:05:26 yes, we agreed on that 20:05:31 the argument was made that it should mimic /usr/bin/touch (which updates the timestamp) but my argument was that we should have at least one of state=touch or state=file do what msot users want. 20:05:46 jtanner: I think `touched=(True|False)` is reasonable 20:06:06 I'd be okay with state=touch doing what /usr/bin/touch does if we can change state=file to create nonexistent files after a suitable deprecation cycle. 20:06:37 it would be redundant with touch _time=preserve 20:06:47 abadger1999: I think you and I agreed on that being the way forward last time 20:06:50 but file: state=file is also used for assertion scenarios right? users don't necessarily want to create 20:07:02 but I think there was talk of a toggle to add that functionality 20:07:04 yep, it was 'stat' before 'stat' 20:07:11 sivel: yep. So currently it's +2 in favor, -1 against. 20:07:19 at this point i just want to rewrite it into dif fmodules 20:07:23 ok, was confused about what was happening :) 20:07:25 haha 20:07:33 state=touched doesn't sound that idempotent 20:07:34 sivel: but you also were +1 to use the diff defaults on touch 20:07:34 now that we are back in sync 20:07:50 (I may have missed some discussion) 20:07:52 separate modules makes the most sense, i just don't know how to weigh the validity of args that overload a parameter 20:07:52 gundalow: it should have never been a state 20:07:56 and its state=touch 20:08:03 I am +1 with this assertion: I'd be okay with state=touch doing what /usr/bin/touch does if we can change state=file to create nonexistent files after a suitable deprecation cycle. 20:08:05 but done on a toggle 20:08:11 state=file < i find that wrong also, state=present/absent type=file/dir/link/etc 20:08:18 (in favor == add a creates parameter so that state=file creates=True would create nonexistent files and state=file creates=False would not create nonexistent files. This would default to false for now and change to True after a deprecation cycle) 20:08:30 * nitzmahone looks at horse running from barn in distance 20:08:38 curious about the background on this 20:08:43 sivel: but at that point, you already provide the functionality, there is no need to change file 20:08:56 state=touch _timestamp=preserve == state=file as toshio wants it 20:09:10 jtanner: pr to add mtime/atime to file module 20:09:17 ok 20:09:39 bcoca: I was also saying there should not be shortcuts like "preserve" 20:09:53 we already have those for mode/owner 20:10:02 might not for owner, 20:10:13 @jtanner There's a loooong history of PRs and issues against file around state=file not creating files. someone finally got a PR added that had the desired creation behaviour but for some reason they called it state=touch and added the timestamp changing as well. 20:10:16 None means update, or an explicit timestamp means to set that timestamp 20:10:20 Thus we are in the place we currently are. 20:10:26 anyway, we had these discussions last week 20:10:34