15:00:42 #startmeeting ansible core public irc meeting 15:00:42 Meeting started Thu Feb 21 15:00:42 2019 UTC. 15:00:42 This meeting is logged and archived in a public location. 15:00:42 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:42 The meeting name has been set to 'ansible_core_public_irc_meeting' 15:01:00 #topic https://github.com/ansible/ansible/pull/50035 15:01:02 @dag? 15:01:10 hey 15:01:22 * bcoca waves 15:01:22 oh no, that one again 15:01:33 well, you put it on agenda ... 15:01:34 we have discussed that one, and people don't understand what it solves 15:01:57 i understand, i just think that we've solved it in other ways in exisitng modules 15:02:22 and find it is not really needed anymore (would have used in 2.3 when we had none of the other fixes) 15:02:30 * alongchamps reading 50035 15:02:40 the only outsanding issue with 'mode' is 2nd variable interpolation, which this does not solve either 15:03:14 bcoca: it may not solve all problems, especially the one that is unsolvable 15:04:04 i even tried a 'yamlism' with !octal but no way to fix that case 15:04:21 dag: so thsi was discussed when i was out? 15:04:33 I don't remember, I think it was discussed in #ansible-devel 15:04:37 should i remove from agenda? was there a resolution? (skimmed logs but didnt see this) 15:04:55 IMO if we don't do anything, the problem will stick around until the next guy wants to solve it 15:05:18 we should have done it in version 0.4, made it to be a string in every case 15:05:19 which problem? that is my issue, we've fixed the issues this is supposed to address already in existing module 15:05:28 and I think by deprecating non-string modes, we get there by v2.12 15:05:32 dag: i dont disagree, but its rained a lot 15:05:38 leaving it as it is, is a problem 15:05:53 i dont understand how that is 15:06:03 maybe not for every existing user that had their systems broken already 15:06:17 bcoca: we force it to be a string in v2.12 15:06:56 and sure, you will bring up the unsolvable problem, but that's just secondary, that's something we cannot solve, but we can bring 95% of the issues to a stop 15:07:17 (and now you will argue that it's not 5%, and we're lost in the discussion again, been there too :-))) 15:08:21 my point, we already solved the other problems ... this just seems redundant 15:08:27 we did not 15:08:36 people can still use octal or integer values for mode 15:08:43 which cases? afaik all cases presented are handled with current code 15:08:51 this PR wants to deprecate octal or integer values for mode 15:08:59 make it strictly a string value 15:09:33 people have argued we need a "strict_str" type, but I disagree, there is value of having a specific type for mode-strings (yes, it could be other formats) 15:10:01 surely a strict string type is useful as well, but a mode-type (which is strict) is especially useful 15:10:12 stric_str has more value since it also handles 'float/version' problem, which we don't actually solve in other ways 15:10:17 I also would like the different types documented (and linked from every parameter) 15:10:23 sure 15:10:34 dag: please show actual examples not currently handled correctly by the file module 15:10:41 I am not saying we don't need a strict string type, but also a mode-type adds value 15:10:48 cause last i looked, the only one is the 'indirection' which we both agree is not solvable 15:10:51 it's not XOR, but AND 15:11:17 it is solvable with native env IMO if we have strict strings 15:11:19 dag: im not disputing that we cannot have both, just that mode does solve any 'current' issues 15:11:33 but I remember you disagreed and honestly I don't care about a corner case that is not solvable according to you anyway 15:11:40 dag: no, since conversion happens before you hit options and you already get a string 15:11:49 ^ i tested 15:11:56 there's the bigger picture and the standard use-case that is problematic, especially if you end up with the wrong file modes 15:12:18 if you have strict string types, that can't happen 15:12:21 there's no conversion 15:12:35 any subsequent conversion won't happen on strings in native env 15:12:38 it shouldn't 15:12:38 yes there is, when the variable gets evaluated and assigned to the other variable 15:12:52 in which case 'type' is not looked at till later when the 2nd variable is actually assigned to the option 15:13:05 ok, but if it's unsolvable, I don't care 15:13:07 so you cannot verify a type 'pre alreayd converted' 15:13:10 I like to fix the 95% problem 15:13:15 not the unsolvable 5% problem 15:13:28 but the 95 is ALREADY fixed 15:13:29 I think what dag is trying to solve is the simple case of a user passing 'mode: 644' directly to the module 15:13:32 no it is not 15:13:35 i havenot seen an example that it is not 15:13:42 cyberpear_: that works 15:13:45 we have tests for it 15:13:59 bcoca: how is that solved ? 15:14:04 does it behave identically to 'mode: 0644' ? 15:14:21 * cyberpear_ remembers being bitten by this issue 15:14:23 cyberpear we don't know what the user intended, YAML gives you a value 15:14:48 we don't know if the user entered it as octal or integer, and whether the value actually makes sense 15:15:17 the only solution was document it more/better in every module 15:15:47 while my solution is to make the documentation state that it is type "mode", and deprecate any non-string value, so that in v2.12 it MUST be a string 15:15:59 and I have explained this at least 4 times now 15:16:12 and it's getting frustrating 15:16:13 cyberpear_: 0 will be octal and converted, unless you quote it 15:16:30 I wonder how others in the Linux community have dealt with this - I'm sure we're not the first group to deal with this 15:17:07 alongchamps: it's a YAML problem, not a Linux problem 15:17:20 yaml + jinja2 + octal/string conversions 15:17:42 yaml problem is easier one to fix, once you start combining the rest is when it gets really bad 15:17:52 hmmm 15:18:08 if you type "mode: 0755" we get integer value 493, if you type "mode: 755" we get octal value 01363 15:18:17 dag: in any case my vote is still -0, im not the only one you need to convince, and im not convinced 15:18:41 im not even the blocker for this feature 15:19:03 why are we discussing it hear, if nobody is around 15:19:12 and nobody puts any comments in the PR 15:19:36 I mean, every discussion here is just a waste of time 15:20:05 maybe better to stop the meeting :) 15:20:07 many times we dont comment on PRs since things are discussed here (logged) and linked, but we should at least ref 15:20:27 there's one vote present 15:20:41 your vote counts 15:21:20 hmm, we have internal meeting, i've just been asked to cancel this one 15:21:25 fwiw, everyone is in another meeting right now. We should have cancelled todays meeting 15:21:32 :( 15:21:35 ok, then we have 1 vote, and one abstained, so this motion is passed :) 15:21:42 dag: no quorum 15:21:44 thanks everybody ;-) 15:21:48 5 needed 15:21:49 exactly my point :) 15:21:59 yep, sorry, i didnt realize the conflicting meeting 15:22:07 was 'optional' in my cal 15:22:15 #endmeeting