19:02:02 <bcoca> #startmeeting ansible core irc public meeting
19:02:02 <zodbot> Meeting started Tue Feb 26 19:02:02 2019 UTC.
19:02:02 <zodbot> This meeting is logged and archived in a public location.
19:02:02 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:02:02 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:02:29 <bcoca> # topic https://github.com/ansible/ansible/pull/50035
19:02:42 <bcoca> dag still wants this, i'm -0, need quorum to go either way
19:03:41 * bcoca wishes for crickets ...
19:03:48 * larsks chirp chirp
19:03:56 * shertel waves
19:03:59 <sdoran> o/
19:04:21 <bcoca> ^ anyone have feedback on topic? do i just call vote?
19:04:25 <felixfontein> I like the proposal
19:04:26 <larsks> Seems reasonable. I see lots of people trip up on this.
19:04:27 <raktajino> I like it. I've gotten burned by this a lot of times.
19:04:29 * alongchamps is here
19:05:26 <bcoca> i mainly think most cases have been fixed already, strict_str fixes the one case this adds and we all agree that 'indirect variable that is octal' is not solvable
19:05:41 <bcoca> so -0 cause it will break playbooks for the 2 people that use octal correctly
19:05:46 <bcoca> vote
19:05:59 <felixfontein> it will first warn them, and only break in 2.12, right?
19:06:33 <bcoca> ah, didnt realize he added that , so 0
19:07:08 <cyberpear> I've taken to using symbolic modes more often these days, though I do use the 0755 representation when not using a symbolic mode.
19:07:20 <felixfontein> at least he wrote: "https://github.com/ansible/ansible/pull/50035"
19:07:22 <felixfontein> oops
19:07:26 <felixfontein> "This implements a deprecation warning if a string was not provided, but by Ansible v2.12 we will only accept string values for type `mode`."
19:07:53 <cyberpear> Seems reasonable to remove the octal functionality, though, as likely lots of folks step on it.
19:08:57 <bcoca> so no one in core cares enough, dag is +1 and community seems in favor, motion passes
19:09:06 <sivel> I'm lurking from my phone
19:09:21 <bcoca> #topic https://github.com/ansible/ansible/issues/52506
19:09:23 * dag is here now too
19:09:33 <bcoca> dag: too late, mode type passed already
19:09:44 <felixfontein> lol
19:10:01 <bcoca> jamescassell?
19:10:06 <maxamillion> bcoca: sorry, got distracted ... I'm +1 to dag's change
19:10:27 <dag> thanks everyone :-)
19:10:27 <bcoca> tis done, on TLS standarization
19:10:42 * dag will rebase that thing now
19:10:59 * bcoca will find new things to review
19:11:13 <felixfontein> I like the tls proposal
19:11:19 <raktajino> love the TLS standardization proposal, what happens to modules that use the 87000 different parameters? Do they get aliases, deprecation warnings, some mixture of these? something else?
19:11:22 <cyberpear> semi-related, but the core module_utils.urls might not currently support a ca_cert option: https://github.com/ansible/ansible/pull/52990#issuecomment-467505434
19:11:32 <bcoca> aliases are fine with me
19:11:36 <cyberpear> I'd say aliases for sure
19:11:46 <cyberpear> similar to what we did for ansible_user and friends
19:11:47 <sivel> I’m +1
19:11:55 <shertel> +1 to aliases
19:12:03 * dag still needs to implement the alias-deprecation facility, but that's unrelated to this one really ;-)
19:12:12 <maxamillion> +1 to TLS standardization
19:12:16 <felixfontein> alias, and slowly deprecate the old names, maybe?
19:12:28 <bcoca> i'll leave that to followup
19:12:44 <bcoca> #topic https://github.com/ansible/ansible/issues/19084
19:13:01 <sdoran> +1 to TLS standardization with aliases for existing terms
19:13:11 <felixfontein> dag: good idea! currently it's kind of annoying that you have to make it two distinct options and add special code to make sure one overwrites the other and one gets warnings
19:13:26 <sivel> bcoca: did you add this one? 19084?
19:13:34 <cyberpear> I added that one
19:13:35 <bcoca> no
19:13:50 <cyberpear> I'd like a way to pass a dynamic set of vars to a role
19:13:53 <bcoca> i already commented in ticket long ago, still dont see the point
19:13:53 <sivel> in theory it’s a good idea.  In practice, it’s not so easy
19:13:58 <bcoca> this is for tasks
19:14:05 <sivel> Ive made 3 attempts and nothing really worked
19:14:34 <bcoca> if you specificaly want for roles, it could be an include/import_role parameter, but i fail to see much value over having them in vars:
19:14:48 <bcoca> it just adds another point of confusion for precedence
19:15:15 <sivel> bcoca: we already declined adding another Param to include/import_role
19:15:42 <cyberpear> seems that the current issue is that each way of passing params or vars to a role is evaluated at "compile" time
19:15:44 <cyberpear> not runtime
19:16:11 <bcoca> imports are compile, includes are runtime
19:16:24 <cyberpear> https://github.com/ansible/ansible/issues/19084#issuecomment-464830345
19:16:39 <cyberpear> that's what I expected, but I couldn't get the dynamic vars passed with include_role
19:17:44 <bcoca> that is not a question of vars being dynamic but improper use of vars: keyword
19:17:56 <bcoca> it does not allow for a template, it only allows for a dictionary
19:18:05 <bcoca> actual dictionary, a var that is a dictionary won't work
19:18:12 <cyberpear> is there a better way to accomplish passing a dynamic set of vars?
19:18:25 <cyberpear> i.e., sometimes I want to pass 3 vars; other times I want to pass 8.
19:18:25 <bcoca> might work in apply: though
19:18:33 <cyberpear> apply didn't work either
19:18:42 <bcoca> cyberpear: you are aware roles always have access to all vars
19:19:03 <cyberpear> (as per the issuecomment above where I tried it)
19:19:05 <bcoca> used a list, unsure if that gets templated before/after before assigned to the 'hidden block'
19:19:27 <bcoca> you tried apply: vars: - "{{myvars}}" , ditch the -
19:19:35 <bcoca> vars is a dict, not a list
19:19:48 <cyberpear> (yes, I'm aware all vars are available)
19:20:13 <cyberpear> I'll try w/o the list, but it got the exact same error with each of the items I tried
19:21:20 <jimi|ansible> i thought vars could be specified as a list too, and they're just turned into a dict
19:21:59 <jimi|ansible> cyberpear: you could put the templated vars under another var in the dict (ie. somevar), then use the vars as somevar.orig_key1
19:22:55 <cyberpear> that would require me to customize each of my roles to support that, and external roles I'm using
19:23:02 <bcoca> i thought hat only applied to play
19:23:12 <jimi|ansible> bcoca: could be i'm mixing that up
19:23:26 <jimi|ansible> i thought it was the same mechanism though
19:23:32 <jimi|ansible> since it's an attribute in base.py
19:23:37 <bcoca> vars_prompt i think is what you are thinking of
19:23:54 <shertel> a duplicate issue makes note of that workaround https://github.com/ansible/ansible/issues/52187
19:24:02 <bcoca> you coudl have simple (dict form) or complex (list of dicts)
19:24:22 <jimi|ansible> yes a list of dicts is the alternative
19:25:24 <cyberpear> removed the list and got the identical "ERROR! Vars in a Block must be specified as a dictionary, or a list of dictionaries"
19:25:48 <cyberpear> this was with the templated vars dict passed to "apply: vars"
19:26:44 <bcoca> wasn't sure that would work, since it probably is just passing them to the block and THEN templating
19:28:25 <bcoca> in any case -1 from me, i don't think we really need this and 'allow for metaprograming in ansible' is a clear deterrent for me
19:28:41 <cyberpear> Seems like expected functionality given the dynamic nature of include_*.
19:29:00 <cyberpear> bcoca: can you elaborate on 'allow for metaprograming in ansible'?
19:29:10 <bcoca> that was comment on PR
19:29:42 <cyberpear> ok
19:29:53 <sivel> Ive mentioned this before, but my recommendation is to make roles capable of working inside and out of loops, so that you can do `vars: {item: “{{ foo }}”}`
19:30:04 <bcoca> `+1 this feature is a must if we want real meta-programming in ansible.`
19:30:27 <sivel> that will make it more flexible, and still acccepts an arbitrary data structure effectively
19:30:41 <bcoca> ^ agree with that
19:31:15 <cyberpear> Would be nice if it were widespread but it requires re-designing each role to support it.
19:31:52 <sivel> After my attempts and understanding that making a role also loopable, I am -1 on trying this further
19:32:08 <bcoca> maybe, i still don't really get the need, i really dont see it, i might be missing something
19:32:10 <cyberpear> I haven't noticed any roles that support that, but perhaps I haven't been looking...
19:32:42 <sivel> many roles don’t do things well
19:32:49 <cyberpear> is it possible to set a default loop_var in a role?
19:32:49 <bcoca> if you reallly loop on roles, vars: would not be the way to pass the elements, you would assing form 'items'
19:33:01 <bcoca> use loop control on the include
19:33:24 <cyberpear> I meant within the role so someone calling the role doesn't need to set loop_control
19:33:45 <bcoca> block
19:34:01 <cyberpear> ok
19:34:09 <cyberpear> I'll try to get a better list of use cases and bring it up sometime later if no better solution emerges.
19:34:14 <bcoca> k
19:34:26 <bcoca> #topic https://github.com/ansible/ansible/issues/52967
19:35:05 <bcoca> 0 from me, i really  dont care either way, easy enough to add ANSIBLE_ one and deprecate via the plugin configs
19:35:06 <cyberpear> When I saw actionable and skippy were deprecated, I noticed that the suggested env var to do the same thing didn't start w/ ANSIBLE_
19:35:21 <bcoca> i think its first non ANSIBLE_ MPD introduced
19:35:28 <cyberpear> I've got a 'reset-env' script that clears out all ANSIBLE_* vars
19:35:35 <cyberpear> woudn't have caught this one
19:35:56 <bcoca> there are other places we accept 'non ANSIBLE_' vars, mostly have to do with specific cloud vars
19:36:39 <bcoca> VAULT_AUTH_METHOD
19:36:43 <bcoca> ^ hashi vault lookup
19:36:46 <bcoca> many examples
19:36:47 <cyberpear> I'm familiar with the OS_* vars, but those are out of ansible scope, IMO.  (i.e., I set them and I can use openstack... commands)
19:37:13 <felixfontein> how about module-specific env vars?
19:37:14 <raktajino> i'd agree that vars consumed by eg cloud services and hashicorp vault would be out of ansible scope. I like the namespaced ansible-specific envvars.
19:37:45 <raktajino> felixfontein: got an example?
19:38:47 <felixfontein> the docker_* modules use DOCKER_* env variables
19:39:01 <bcoca> ^ many examples, almost every cloud module
19:39:23 <raktajino> i haven't done any work with docker at all, so bear with me... those are consumed directly by docker stuff, yeah? I'd think those would fall into the "not within ansible scope" category
19:39:30 <agaffney> felixfontein: those are for use by the libraries that the modules use, not directly by ansible. you also don't need them set on the controller
19:39:48 <felixfontein> raktajino: no, they are parsed by the ansible code only
19:39:48 <bcoca> lookups and callbacks have plenty of those
19:39:57 <felixfontein> agaffney: not true for the DOCKER_* env vars
19:40:07 <bcoca> agaffney: in some cases we parse them to do precedence, then pass value to lib
19:40:08 <felixfontein> (except for docker_stack, which calls the docker CLI directly)
19:42:39 <felixfontein> in case of the docker env vars, these are parsed by ansible and the values are passed on to docker-py. docker-py is not using any of these variables (it can be told to use env variables, but we're not doing that)
19:42:41 <cyberpear> IMO, if ansible is defining a var, it should start w/ ANSIBLE_, but if it's leveraging someone else's var, the name of that var is beyond the scoep
19:43:10 <bcoca> fine with me
19:43:10 <felixfontein> (which is not really optimal, since for example some docker TLS related env variables are interpreted differently by ansible, docker-py and docker cli.)
19:43:14 <nitzmahone> yeah, much less chance of unintentional collision
19:43:23 <sdoran> Changing that variable name is fine provided we keep the existing one working.
19:43:35 <bcoca> sdoran: easy to do and even show deprecation
19:43:40 <sdoran> cyberpear: +1
19:43:43 <bcoca> config api allows for it
19:43:47 <sdoran> Sweet. :)
19:44:10 <bcoca> +0 .. mostly cause its not a priority imho, but fine if someone puts the time in
19:44:18 <bcoca> anyone against?
19:44:26 <sivel> Nope
19:44:26 <sdoran> Nope. PRs welcome.
19:44:35 <bcoca> motion passes!
19:44:49 <bcoca> #topic https://github.com/ansible/ansible/pull/52518
19:45:08 <nitzmahone> DOITDOITDOITDOIT
19:45:39 <bcoca> i really dont care about those facts .. but im also working on a 'proxy deprecated' variable , that will actually notify on use
19:45:48 <bcoca> i would wait for that before we start deprecating returned facts
19:46:11 <nitzmahone> yeah, several of us have that on the pile ;)
19:46:36 <bcoca> nitzmahone: i've reversed teh approach, proxy the 'value' instead of having top proxy inspector
19:46:39 <nitzmahone> It's pretty straightforward except for the Python types that can't be emulated (eg int)
19:46:50 <nitzmahone> bcoca: that's what mine does too
19:47:04 <bcoca> ah, have not seen yours .. also stuck at int
19:47:06 <nitzmahone> just basically a Jinja "tripwire"
19:47:13 <bcoca> ... great minds ...
19:47:25 <bcoca> str/rpr 'deprecation call'
19:47:45 <felixfontein> hmm, I would still like to announce that they are deprecated ASAP
19:48:04 <felixfontein> though having a feature which warns about them being used would be great!
19:48:07 <bcoca> -0 .. dont care enough to strongly opose, not sure anyone uses those facts
19:48:12 <nitzmahone> no problem with that, just can't actually show runtime warnings (or really start the clock for removal) until the capability exists
19:48:25 <felixfontein> the facts returned by docker_container have been renamed in the past
19:48:30 <bcoca> PR puts clock at 2.12
19:48:45 <felixfontein> I hope nobody really uses them...
19:48:46 <bcoca> felixfontein: docer_container was rewritten
19:49:03 <sdoran> +1: non-facts modules should not be returning ansible_facts
19:49:08 <felixfontein> bcoca: you mean the old docker module?
19:49:28 <felixfontein> bcoca: during the lifetime of docker_container, the return facts was renamed when the docker connection plugin was added (according to the docs)
19:49:58 <bcoca> you probably know recent history better than i
19:50:19 <bcoca> if i had been aware, i would have objected
19:50:21 <felixfontein> that part of the history I only know from the docs :)
19:50:32 <bcoca> he
19:50:38 <sivel> I am +1 on having docker modules not return ansible_facts, it's evil
19:50:53 <bcoca> i stopped using docker a while back, mostly lxc/lxd and vbox now, so i lost interest in the modules
19:50:55 <felixfontein> I've been using the module for a long time, but I never used the facts (or even knew they were being returned)
19:51:09 <bcoca> why remove then?
19:51:53 <felixfontein> because I don't think facts should be returned for something which is not host specific
19:51:55 <sivel> I use docker_container quite a bit, and iirc if you register you have to use whatever.ansible_facts.foo
19:51:58 <bcoca> felixfontein: also, look at INJECT setting , set to 'off' avoids most of the problem sstated in PR
19:52:30 <felixfontein> sivel: that's true, except that now (in devel) you can also use whatever.docker_container directly (without ansible_facts inbetween)
19:52:41 <felixfontein> I've added that recently, so people can stop using that ansible_facts inbetween
19:53:06 <sivel> they should have never return ansible_facts to begin with, so I'm still +1 on some form of removal
19:53:17 <sivel> about 7 minutes remaining here
19:53:18 <felixfontein> bcoca: do users know about this?
19:54:33 <bcoca> its documented, i have not gone door to door to tell everyone
19:55:03 <raktajino> can we add "send bcoca door to door to tell users about new features" to the next core meeting agenda :V
19:55:04 <felixfontein> can it also be disabled on a per-task level?
19:55:16 <bcoca> no, its global
19:55:46 <bcoca> raktajino: that passed 2 yrs ago, still worki.ng on the clone vats to make it so
19:56:01 <raktajino> i'll send some interns
19:56:24 <bcoca> good, teh first borns in my basement need help to manage the microbrewery
19:57:02 <bcoca> k, anyone really against this change?
19:57:07 <bcoca> is there a docker WG?
19:57:15 <bcoca> is felixfontein THE docker WG?
19:57:31 <felixfontein> feels like most if it, sometimes...
19:57:44 <bcoca> k, i count this as 'motion passes'
19:57:49 <felixfontein> ok, thanks!
19:58:00 <felixfontein> and please implement that "warning when variable used" feature ;)
19:58:01 <bcoca> with that and with 2mins left, going to end it now, carry over rest of items to next meeting
19:58:08 <bcoca> felixfontein: we are working on it
19:58:12 <bcoca> #endmeeting