19:01:25 <bcoca> #startmeeting ansible core public irc meeting
19:01:25 <zodbot> Meeting started Tue Jan 15 19:01:25 2019 UTC.
19:01:25 <zodbot> This meeting is logged and archived in a public location.
19:01:25 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:25 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:01:29 <bcoca> @dag?
19:02:36 <bcoca> k, skipping his issues i believe he has conflicting meeting now
19:03:04 <bcoca> #topic https://github.com/ansible/ansible/pull/50705
19:03:15 <bcoca> federico olivieri?
19:03:45 <nitzmahone> and then
19:03:56 * gundalow waves
19:04:50 <bcoca> well, unsure what pettitioner wants and also seems more appropos for network meeting
19:06:05 <bcoca> #topic https://github.com/ansible/ansible/issues/50503
19:06:07 <bcoca> fun one
19:06:19 <bcoca> @sdoran, want to make case?
19:07:06 <sdoran> This is tricky.
19:07:25 <bcoca> guessing that is why you wanted it brought up here?
19:08:29 <sdoran> I put it on the agenda because it was eating up triage time.
19:08:37 <sdoran> And we should discuss it further.
19:09:18 <sdoran> I think warning is definitely a good idea. Since right now it silently transforms the data.
19:09:43 <nitzmahone> I lean that way as well
19:09:50 <bcoca> i think config toggle to a) stay as current, b) warn c) error by making it strict conversion
19:10:04 <nitzmahone> Definitely not a failure- if we want that, it should be a different type, eg, `stringnoreallyimeanit`
19:10:06 <sdoran> I’m not sure on the solutions mentioned. A command line flag was brought up as a way to enable it.
19:10:16 <bcoca> module_string_conversions: transparent|warn|strict
19:10:22 <sdoran> Would a config option be “too sticky”?
19:10:37 <nitzmahone> -1 to the command line flag, but I could get behind a config opt-out
19:10:45 <bcoca> well, i would say requiring a cli option makes it too variable and plays wont work the same
19:10:54 <nitzmahone> ETOOMANYCLIOPTS
19:10:58 <sdoran> I was thinking that too.
19:11:02 <felixfontein> hi everyone
19:11:05 <bcoca> while config will make it 'stable'
19:11:08 * bcoca waves
19:11:14 <sdoran> Plus another option to (maybe) our in the Tower UI.
19:11:14 <alb0t> felix!
19:11:37 <sdoran> So a config option makes the most sense.
19:11:51 <sdoran> Hopefully someone won’t set it and forget about it. :)
19:12:09 <bcoca> we seem to have tacit agreement on making this a toggle
19:12:14 <nitzmahone> Defaulting to warning on conversion to string makes sense to me
19:12:29 <bcoca> and .. i was going to say .. we can now start fighting about the default
19:12:45 <felixfontein> +1 for warning by default
19:12:52 <felixfontein> error by default will probably break way too much
19:12:54 <nitzmahone> The people that need it most are the ones that will never opt-in to checking
19:12:55 <sdoran> @bcoca So the config option has three values?
19:13:13 <bcoca> i would say +1 for 'as is', change to warning in future version and to strict in even more future version
19:13:23 <sdoran> Just want to make sure I understood what you described earlier.
19:13:37 <bcoca> sdoran: that is my thought, many wont care about warning, we have a lot and no good ways to switch off
19:13:39 <nitzmahone> basically ignore/warn/error
19:13:49 <bcoca> yep
19:13:56 <bcoca> ^ i like those values better
19:13:57 <sdoran> Currently we have “ignore”.
19:14:02 <nitzmahone> I'm not sure what the benefit of waiting to make warn the default is though
19:14:21 <felixfontein> in particular if this one's easy to turn off with the correct config value
19:14:24 <bcoca> nitzmahone: minor, just ensure toggle works before we make it the deafult
19:14:31 <bcoca> i can be swayed on that, easily
19:14:58 <nitzmahone> We've got enough time before 2.8 freezes that if we do it now, we can revisit/fix if there are problems
19:15:20 <bcoca> roger, sdoran want to add ticket/project with what we decided here?
19:15:43 <sdoran> I’m trying to think what that’ll look like to most users. Trying to avoid warning fatigue.
19:15:44 <bcoca> or before that, any opposition to solution? a) add toggle with ignore/warn/error, b) default to warn
19:15:58 <nitzmahone> I'd be much more conservative about that if we were defaulting to `error`, but with warn-as-default, worst case it's an annoyance
19:16:06 <bcoca> that is my only concern, we went from 'not enough info' to 'nagging
19:16:27 <bcoca> but that is very subjective threshold
19:16:34 <sdoran> Can they change something easily to make the warning go away? Quote the value maybe?
19:16:37 <nitzmahone> But I don't think delaying changes that- most users aren't digging through the config base looking for new knobs to turn ;)
19:16:42 <nitzmahone> Exactly
19:16:50 <sdoran> Ok.
19:16:56 <nitzmahone> Quoting the value will make it a string, so it's a very easy fix
19:17:07 <felixfontein> maybe set it to warning on devel, and directly after branching stable-2.8, set it to ignore on there? so that at least on devel it's warning all the time?
19:17:15 <sdoran> As long as we explain the fix in a well crafted warning, I’m ok with warm being the default.
19:17:26 <nitzmahone> It'd be harder if we were going the other way (eg, warning on string to int conversion) since a number of places have to do that by default
19:17:34 <sdoran> That seems helpful since it’s brining to light something they may not have been aware of.
19:17:35 <bcoca> add config entry to warn message to 'turn off' and i think we are golden
19:18:00 <sdoran> *warn
19:18:16 <sdoran> (Warm being the default would be an interesting setting)
19:18:17 <nitzmahone> eg `this message can be disabled by setting BLA to "ignore" in ansible.cfg`
19:19:05 <bcoca> and as felixfontein points out, we can change default before release if we see it causes too much distress
19:19:08 <felixfontein> maybe it would also help if that feature could be toggled per task/include/...? or is that too much complexity?
19:19:22 <nitzmahone> If the config entry includes a var, that would work
19:19:41 <bcoca> it could, since its task level and vars are present
19:19:42 <nitzmahone> (well, and if we look it up in host context)
19:19:53 <bcoca> but i think a warnings: on|off task level feature might also work
19:20:01 <felixfontein> that would allow people to convert their stuff role by role / task by task, depending on how many warnings they get
19:20:44 <nitzmahone> I'd go for small (define a var on the config entry) for now rather than new play/task synatx
19:21:14 <sdoran> That seems too wordy. If you’re togging warnings at the task level, just fix the task. You’re already there.
19:21:25 <sdoran> Let’s start with a global config setting.
19:21:43 <bcoca> im ok either way, i do see var as bit of overkill but im fine with it
19:22:13 <bcoca> going to clsoe this as 'fix by toggle' we can bikeshed on teh fix itself once we have PR
19:22:30 <sdoran> Can I write this up in a WIP PR? Or is there a better context?
19:22:32 <bcoca> #action sdoran to add ticket to 2.8 project for 'string conversino warning toggle for module optoins'
19:22:39 <bcoca> works4me
19:22:44 <sdoran> K.
19:25:17 <bcoca> #topic https://github.com/ansible/ansible/pull/49138
19:25:26 <alb0t> yahoo
19:26:36 <bcoca> so im going to guess, you want someone else to review so new module and category can be added?
19:27:11 <alb0t> im not sure how the process works, but that sounds about right
19:27:46 <bcoca> i see felixfontein already gave it attention ... anyone have time to give this a once over?
19:28:06 <bcoca> alb0t:  we are down a 'cloud team' so its been hard to get time for core to look at things
19:28:56 <bcoca> isnt this more a dtabase than a cloud thing?
19:28:57 <alb0t> bcoca: no worries, I can wait. We're already using it in production so reaping the benefits, so I'm not in a rush… but I think it would be useful to a lot of other people.
19:29:07 <alb0t> Yeah it's for a NoSQL database.
19:29:33 <bcoca> sorry its correclty under /database/ ... i must be seeing things, could swear it was /cloud/ 20s ago
19:29:43 * bcoca looks for coffee IV
19:29:48 <felixfontein> :)
19:30:08 <alb0t> head in the clouds :P
19:31:10 <bcoca> k, if no one else i'll add to my list .. but its a long list, i would try as felixfontein suggests and ping users during community meetings
19:31:29 <bcoca> #topic open floor
19:31:42 <alb0t> it looks like gunadlow added an approval
19:31:54 <felixfontein> I think this PR is looking for core reviews: https://github.com/ansible/ansible/pull/50335 :)
19:32:13 <bcoca> gundalow qualifies .. last i looked
19:32:41 <bcoca> he should have rebuild_merge or shipit, approve wont get it merged by bot
19:33:03 <felixfontein> new modules aren't automerged anyway, I thought?
19:33:17 <bcoca> so rebuild_merge
19:33:44 <felixfontein> ah, that one does? nice :)
19:34:35 <bcoca> just cause stale CI
19:34:40 <bcoca> forces new ci run
19:34:55 <felixfontein> I mean merge things ansibot usually doesn't automerge
19:35:02 <alb0t> thanks everyone :D
19:35:38 <bcoca> felixfontein: yep, you should be able to use that for docker stuff now
19:37:10 <felixfontein> haven't really had a chance to try it out yet ;)
19:40:46 <felixfontein> alb0t: congratulations for your first module :)
19:41:26 <felixfontein> (assuming there are no surprises ;) )
19:42:27 <alb0t> felixfontein: thanks for all your help. I've learned a lot :) and will be brushing up on my python more to make this more stable
19:43:54 <felixfontein> you're welcome!
19:45:58 <bcoca> ok, if no new business in next min, closing meeting for today
19:46:11 <alb0t> *wave*
19:46:33 <felixfontein> ok, I got something
19:46:41 <felixfontein> https://github.com/ansible/ansible/issues/50319
19:47:13 <felixfontein> most docker modules have various options which require minimum API versions and minimum docker-py versions. we've collected a lot of them so the modules do checking on startup
19:47:32 <felixfontein> it would be nice to also have that in the documentation, but without doing the work twice (i.e. have two different datasets)
19:47:53 <felixfontein> does anyone has a good idea how to do that?
19:52:04 * cyberpear waves
19:54:02 * felixfontein waves back
19:54:07 <cyberpear> any time for https://github.com/ansible/ansible/pull/50327 ?
19:54:39 <bcoca> thought we had already discussed that
19:54:54 <cyberpear> k, didn't know if we needed followup
19:55:07 <cyberpear> I made the changes discussed
19:55:15 <bcoca> i'll add to my review list, unless someone else wants to tackle first
19:55:50 <cyberpear> thx
19:56:02 <bcoca> #endmeeting