19:07:55 #startmeeting ansible core public irc meeting 19:07:55 Meeting started Tue Jan 5 19:07:55 2021 UTC. 19:07:55 This meeting is logged and archived in a public location. 19:07:55 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:07:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:07:55 The meeting name has been set to 'ansible_core_public_irc_meeting' 19:08:34 * cyberpear listens in 19:09:23 o/ 19:09:26 #topic hash_behaviour deprecation, document why and replacements 19:09:42 @jerrac ? 19:10:07 not sure whether they are around, but I'm also interested in that 19:10:15 ^ anyone else want to weigh in on topic? 19:10:49 skipping then and trying again next meeting 19:10:54 #topic open floor 19:10:56 (disclaimer: I'm not using it, and I understand that people don't like it :) ) 19:10:56 I am in favor of removing it because it causes more problems than it solves. 19:11:26 I'm interested in whether it blocks / makes harder maintenance (except for being there and needing to be tested) 19:11:36 is there a link for the hash deprecation? 19:12:04 afaict i have not seen any issues related to it in long time, so not sure what problems it causes or what the maintenance issue is (its really restricted to combine_vars function) 19:12:09 cyberpear: https://github.com/ansible/ansible/pull/63300 19:12:18 felixfontein++ thanks! 19:13:34 yeah, probably best to get rid of it... I just hope no one is actually using it; it basically creates two classes of incompatible sets of playbooks/roles 19:13:46 cyberpear: some people are using it intensively apparently 19:14:05 and don't like the idea of rewriting all their ansible roles, playbooks, inventories, ... 19:14:18 This comment from the author of the original feature also provides some insight. https://www.reddit.com/r/ansible/comments/a7x92q/in_which_case_hash_behaviourmerge_can_become/ec8mf7f/ 19:14:19 I fully understand why one might choose to use it... the mount of indirection I've had to do to make things work without it sometimes has been non-trivial 19:14:38 I do not like the merge behavior because my two remaining functioning cells cannot keep up with the layering. But quite a few of my coworkers use that feature. 19:14:39 here's a comment by a user: https://github.com/ansible/ansible/issues/73089#issuecomment-753009329 19:15:06 the issues linked in the agenda have some more comments from users 19:15:10 s/cells/brain cells/ 19:15:24 in defaults, I'll often have: `myvar: {{myvar_default}, myvar_default: default_value` just so someone can get the default to further override it, either by map combining or string addiotn, etc 19:15:25 tadeboro: I'm happy you have more than two functioning cells :D 19:15:58 sdoran: the main issue is not even against the deprecation but how it was done, lack of info and lack of alternatives, people really frustrated cause of a lack of a way forward 19:16:13 Yeah, I was about to say that. 19:16:13 But as long as they can achieve the same thing with more explicit constructs, they will be fine it the removal. 19:16:16 though some have suggested some mitigations (custom vars plugins) 19:16:20 We need to add better documentation about this. 19:16:36 tadeboro: tehy cannot, they can come 'close' but in the end it is germain to 'varsmanager' class 19:17:21 so you can have include_vars merge (there is PR in queue) or use custom host_group_vars vasrs plugin, but that only handles a subset of the 13+ ways to introduce/overwrite vars 19:17:25 I wonder how much the workarounds (like in https://github.com/ansible/ansible/issues/73089#issuecomment-752903788) solve, and which things that are in active use aren't covered by them 19:17:29 it's two different mindsets, and apparently since folks are using it extensively, it might be harder to get rid of (after reading the issue comment linked by felixfontein) (as the user re-iterates, locking issues is still annoying ,btw) 19:17:43 felixfontein: i think i answered you preemptively 19:18:10 bcoca: I also saw that someone else already mentioned the vars plugin ;) (though that was in a time when vars plugins didn't work in collections) 19:18:27 cyberpear: at least we get to see comments now, unlocked they were just ignored, so might be less annoying but also more frustrating in the end as we dont see those 19:18:40 felixfontein: that was 2.8 .... 19:19:20 bcoca: vars plugins in collections only work since 2.10 19:20:26 thought we backported that fix 19:20:43 it's too bad that jerrac isn't around, it would be interesting to talk to someone who actually uses it a lot 19:21:10 bcoca: hmm maybe I have to try again, but I think I had to explicitly disable tests for a vars plugin in 2.9 to make them 'pass' 19:21:16 it has to do with data organization, not everyone looks at data the same way, specially those comming from puppet/chef are used to 'vars being scoped to group/function' 19:22:25 in ansible vars are 'scoped' to play object or host, groups are just a 'handy mass assignment construct' when it comes to vars, yet people assume otherwise, also about inheritance and how it should work 19:23:11 i dont like hash_behaviour peronsally, i always thought it should be something available at the variable level, but many people dont want to bother with that fine grained approach 19:23:47 that said, im not one of the people advocating for it's removal either, much less lacking a real alternative 19:25:50 how about not deprecating it, but instead add a big fat "IF YOU USE THIS, WE WILL NOT SUPPORT OR HELP YOU!" to the docs? :) 19:30:43 and providing some ways to migrate off it, like having a vars plugin which merges (maybe in community.general)? 19:34:05 again, that is only partial solution as that only handles merges for host_vars and group_vars intenrally, not when they merge with same var name from other sources 19:34:23 vars: listfrominventory: [addtional, elements] 19:34:47 not saying we cannot create such plugin (basically copy/paste existing + combine_vars code) 19:35:19 just that its only partial solution/mitigation 19:35:23 well, it would be a first step in easing transition (since certain overwrites can be kept), and by no longer deprecating hash_behavior people have more time for it anyway 19:37:00 It will not be removed until 2.13, which is probably about two years away. 19:37:44 sdoran: i believe we changed the cycle to be 2yrs from deprecation not 4 versions anymore 19:37:55 some people might still want to use it after that 19:38:20 im sure, why i never pushed for it to be deprecated 19:38:33 even though i pushed hard for it never to be included .... 19:39:19 :) 19:39:42 unfortunately that happened and now people are using it 19:39:48 same reason with_ was never deprecated 19:40:10 people were using it, they just noticed the deprecation 'now' as they upgraded to 2.109 19:40:12 2.10 19:42:28 out of curiosity, what would need to happen that the deprecation is removed? 19:45:23 remove the deprecation entry, clog 19:46:29 and put it up for discussion here? 20:01:38 Yes, we'd need to discuss it more here. 20:01:49 Not everyone is back from holiday yet. 20:02:08 k, going to end it now, missing key people to get anywhere constructive 20:02:12 #endmeeting