19:00:29 <bcoca> #startmeeting core public irc meeting 19:00:29 <zodbot> Meeting started Tue Jan 8 19:00:29 2019 UTC. 19:00:29 <zodbot> This meeting is logged and archived in a public location. 19:00:29 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:29 <zodbot> The meeting name has been set to 'core_public_irc_meeting' 19:00:40 <bcoca> #topic https://github.com/ansible/ansible/pull/28662 19:00:54 <maxamillion> .hello2 19:00:55 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com> 19:01:16 <bcoca> @dag ? 19:02:23 <bcoca> @jamescassel ? 19:02:28 * cyberpear waves 19:02:38 <bcoca> #topic https://github.com/ansible/ansible/pull/50327 19:03:57 <cyberpear> one of the needs for basic regex escaping came about when needing to escape something passed to sed 19:04:11 <bcoca> not against change, but not sure 'basic' is best name, 'posix' seems more appropos 19:04:34 <cyberpear> I'm fine w/ any name we give it. POSIX supports basic and extended. 19:05:56 <bcoca> ^ anyone else? 19:06:23 <cyberpear> "posix-basic"? 19:07:01 <bcoca> might be ok with basic as long as docs/example say its 'posix basic' .. i know there is 1 other regex std that uses both .. but i cannot recall and im pretty sure its too obscure/unused 19:07:31 <sdoran> Are we renaming the filter or just trying to figure out what to call it in the docs? 19:07:40 <bcoca> the other option is new filter posix_escape(extended=false) 19:07:40 <cyberpear> I also retroactively named the existing functionality as "python" and left it as default; I'm okay to rename that if it's desired. 19:08:30 <bcoca> so +1 functionality ... but open to bikeshed on interface 19:08:36 <sdoran> Ah, I think I see it now. 19:09:25 <bcoca> i really dont have strong pref, was just confused by 'basic' until i read the comments, which is why i thought another more obvious name shoudl be used 19:09:43 <nitzmahone> +1 to new re_type arg vs new filter 19:10:18 <cyberpear> At the very least, I'll s/basic regex/POSIX basic regex/g in the docs. 19:10:41 <sdoran> Yup, just did some reading I prefer posix basic as that's the official name. 19:10:50 <sdoran> It's more accurate. Basic is ambiguous. 19:10:56 <nitzmahone> `posix_basic` `posix_extended` `python`? 19:11:04 <cyberpear> so re_type="posix-basic"? 19:11:12 <cyberpear> that works 19:11:15 <nitzmahone> underscore though please, no dash 19:11:23 <cyberpear> got it 19:11:26 <sdoran> +1 19:11:55 <bcoca> +3, no oposition .. its small enough feature im not going to look for quorum 19:11:56 <cyberpear> okay to alias 'posix_extended' to 'python'? 19:12:04 <bcoca> are they same? 19:12:13 <cyberpear> I think so... 19:12:16 * bcoca has not looked closely to python regex quoting 19:12:17 <cyberpear> open to being corrected, though 19:12:31 <sdoran> I would hold off on that until you verify it. 19:12:34 <cyberpear> k 19:12:45 <sdoran> Because I don't know either and would hate to be inaccurate. 19:13:22 <sdoran> You can put a link/note in the ticket if you find out that is the case and make it so (if it's accurate). 19:13:41 <cyberpear> will do 19:13:42 <sdoran> Otherwise, don't conflate them. 19:13:43 <sdoran> Thanks. 19:13:45 <bcoca> k, cyberpear we can review again after changes, but seems like we will most probably merge aafter the tweaks 19:13:50 <bcoca> going to close this for now 19:13:56 <bcoca> #topic https://github.com/ansible/ansible/pull/50642 19:14:03 <bcoca> @federico ? 19:14:48 <bcoca> #topic https://github.com/ansible/ansible/pull/50564 <= should we revert? 19:16:16 <bcoca> any thoughts? 19:17:04 <nitzmahone> I can't recall off the top of my head- would this cause them to reset between plays? 19:17:10 <bcoca> i'm with @shertel on this one, think reverting to previous behaviour and document the limitations of clear_facts for this case 19:17:14 <nitzmahone> (things set via set_fact) 19:17:25 <bcoca> nitzmahone: no, it causes set_fact to have less precedence 19:17:49 <bcoca> when using 'cacheable' ... in the same play, currently it has less precedence, but only when persisted across runs 19:18:07 * bcoca whishes he had tardis to oppose this 'feature' more strongly in past 19:18:16 <nitzmahone> yeah 19:18:25 <bcoca> set_fact is a misnomer to start, sets a 'host var for current run' with high precedence 19:18:28 * nitzmahone looks wistfully at horse running from barn in distance 19:18:53 <shertel> Yeah :-/ 19:18:55 <sdoran> set_host_var_for_current_run has a nice ring to it ;) 19:18:58 <bcoca> cacheable=true adds the 'ability' for this variable to be 'cached with facts' , but we set it x2 to keep 'normal precedence in current play' 19:19:25 <bcoca> this creates problem since meta: clear_facts, will remove the 'cached' version but not the 'set_fact' version 19:19:44 <bcoca> my pr fixed this and i meant to discuss here, but got merged by acccident beforehand 19:20:00 <bcoca> so now i wanted to consult with more people before i revert or keep the new behaviour 19:20:14 * bcoca might just deprecate set_fact and remove the whole problem 19:21:04 <nitzmahone> holy-cure-worse-than-disease, Batman 19:21:42 <nitzmahone> Seems like trying to correct that with a new action might be better than potentially breaking the existing one, for better or worse 19:22:09 <shertel> +1 19:22:16 <bcoca> nitzmahone: hence the deprecation 19:22:40 <cyberpear> Looks like this change makes set_fact w/ cacheable=yes always operate at low priority, which could break existing playbooks and can be achieved by checking whether said fact exists already. 19:22:41 <bcoca> set_var: scope=host/play/fact 19:22:59 <bcoca> cyberpear: why i didnt want it merged 19:23:00 <cyberpear> +1 set_var w/ scope 19:23:46 <dag> o/ 19:23:54 <bcoca> its something i realized after writing the PR, it can have nasty consequences 19:24:00 <nitzmahone> Yeah, I'm leaning toward "damage done, EHORSENOTFOUND", the fix seems likely to cause more problems than it solves 19:24:00 <dag> I have a schedule conflict :-/ 19:24:10 <bcoca> but we also have the 'clear_facts' bug, so i wanted more heads thinking on this before i decide 19:24:28 <bcoca> dag: we can discuss your stuff on thursday 19:24:47 <dag> bcoca: fine, thanks ! 19:27:58 <bcoca> so can infer everyone is for revert + update clear_facts docs? 19:28:28 <bcoca> with possible 'obsoletion' new module in future (set_host_var) that will solve the problem in a better way? 19:28:32 <sdoran> Yes. Seems the least problematic route. 19:28:53 <bcoca> k, glad i had this sanity check 19:29:02 <bcoca> #topic open floor 19:29:54 <cyberpear> I've been looking for a good way to get the equivalent of vars.keys() since 'vars' isn't supposed to exist... Any ideas? 19:32:48 <cyberpear> Perhaps something like "lookup('vars', '*', print_var_names=True)" ? 19:35:05 <bcoca> i have been thinking about that one, but i have no good solution 19:35:17 <agaffney> what's the use case? the need to get a list of all local vars implies you're doing something the hard way 19:35:18 <bcoca> specially since 'vars' already does not have 'all vars' 19:35:39 <cyberpear> what's missing from 'vars'? 19:35:54 <bcoca> some magic vars, corner cases, depends on context 19:35:54 <cyberpear> vars.keys() seems to meet my current needs fwiw 19:36:09 <bcoca> ^ but agaffney poses good question, 'what is the use case?' 19:36:27 <agaffney> cyberpear: does hostvars[inventory_hostname].keys() not work for you? 19:36:31 <bcoca> any of what i can think of is covered by 'is defined' 19:36:38 <bcoca> agaffney: that lacks play vars 19:36:51 <agaffney> bcoca: I know, but I don't know what the use case is yet 19:37:05 * jtanner has been sitting in ansible-devel for past 10 minutes thinking "this is a slow meeting" 19:37:29 <cyberpear> My case has been to select all vars than end in some suffix or start w/ some prefix 19:37:41 <cyberpear> these include role default vars 19:38:28 <cyberpear> One use case was to grab <rolename>_external_urls vars from a series of roles and download those urls for offline air-gapped use. 19:38:30 <bcoca> a find vars seems to be more appropos 19:38:42 * bcoca gives jtanner some coffee 19:38:59 <bcoca> 'match_vars', '*_suffix' 19:39:17 <cyberpear> something like would fit the bill 19:39:18 <bcoca> lookup('vars', match='' ... 19:41:33 <bcoca> cyberpear: put in feature request (or PR) to extend vars plugin with a match .. for that case '*' would also return all keys 19:41:54 <cyberpear> thanks, will do. 19:42:37 <bcoca> can implement just looking at the 'variables' variable the lookup gets (ALL vars are in there) 19:43:19 <bcoca> but it will return the values ... 19:43:40 <cyberpear> thanks for the tip. I'll give a quick shot at implementing, otherwise I'll open an RFE if I run into trouble. 19:43:44 <bcoca> might need extra to 'return dict with key instead of value' ... though that is a diff lookup imho 19:49:27 <bcoca> ok, if nothing else, going to end it now 19:49:48 <bcoca> #endmeeting