19:03:05 #startmeeting Ansible Core Public IRC Meeting 19:03:05 Meeting started Tue Dec 3 19:03:05 2019 UTC. 19:03:05 This meeting is logged and archived in a public location. 19:03:05 The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:03:05 The meeting name has been set to 'ansible_core_public_irc_meeting' 19:03:34 #topic https://github.com/ansible/ansible/pull/64959 19:04:52 bidord: you around to discuss your PR? 19:05:05 yep 19:05:09 * felixfontein waves 19:05:12 o/ 19:08:30 so basically, it's a simple bugfix on `extract()` that didn't work good with `| default`, i was wondering if it could be merged someday, and also if I missed something in the PR (that new_contributor label must be here for a reason) 19:09:29 * jillr reading pr and related issue.. 19:10:58 isn't it better to keep `isinstance(data, Undefined)`? IIRC AnsibleUndefined extends Undefined 19:11:03 getting on the meeting agenda is definitely a good step for getting things merged that affect the core engine, we had quite a lot of folks out last week due to a holiday in the US though 19:12:03 bidord: what is environment.getitem(...)? 19:12:26 felixfontein makes sense, it's checking a value returned from the other modified method, so there's no chance that it wont return an AnsibleUndefined, iirc I did it like that just so I don't have to import both 19:14:16 bidord: could it be that self._variable_manager.get_vars(host=host, include_hostvars=False) also returns Undefined? 19:14:24 agaffney: it returns what Jinja2 container.item would return, so it's behaving exactly as Jinja2 was configured (ie: returning an AnsibleUndefined) 19:14:35 ah 19:15:22 as for the AnsibleUndefined vs. Undefined thing, any place where Undefined is used is probably just something that I missed when I created AnsibleUndefined and have just gone unnoticed until now 19:19:02 felixfontein: maybe, I can't tell for sure, that's a good point, instaciating AnsibleUndefined but using Undefined for isinstance() might be the safest way 19:19:31 agaffney: what do you prefer? 19:20:22 well, AnsibleUndefined is required to get the new behavior that it introduced (cascading the Undefined class through further accesses to allow |default() with foo.bar.baz.abc.123 nested lookups) 19:21:21 I have no preference on `is AnsibleUndefined` vs. `isinstance(..., Undefined)` 19:21:23 after taking a look at VariableManager.get_vars(), I really don't think it can return anything else than a dict() actually 19:21:43 fwiw, we triaged this today, and have it assigned for a core member to review shortly 19:21:57 we said it looks right at first glance, but decided to review more in depth 19:22:05 not that you can't talk about it here, just giving an update 19:22:09 ok, thanks! 19:22:16 since you don't see the internal triage details :) 19:22:24 sivel types faster than I do :) thx 19:22:50 crazy fingers! 19:23:07 and with that, I shrink into the shadows to go eat lunch 19:23:24 enjoy lunch! 19:24:50 so in that case, 19:24:52 #topic https://github.com/ansible/ansible/pull/55268 19:25:17 not sure if evitalis is around 19:27:13 there's quite a bit of history here, not sure we can accomplish much without them present 19:27:44 it looks like someone with OpenBSD knowledge / access to such a system is needed 19:27:55 yah 19:28:09 #topic open floor 19:28:17 where's bcoca when you need him? :) 19:28:31 on a much earned vacation! :) 19:28:55 I've got a FreeBSD VM but not OpenBSD, but my BSD knowledge is minimal 19:29:25 it's been quite a few years since I did much of anything on BSD 19:31:26 the only BSD I've been using lately is macOS 19:31:41 and I didn't do much more with it than starting Safari and testing a webapp :D 19:32:31 is it even BSD anymore 19:32:36 I assume Darwin has diverged sufficiently at this point to be barely recognizable as a BSD 19:33:12 if no one has any opens we'll go ahead and call it for the day 19:33:15 thanks folks! 19:33:22 #endmeeting