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