15:00:03 #startmeeting Ansible Core Public IRC Meeting 15:00:03 Meeting started Thu Jan 7 15:00:03 2021 UTC. 15:00:03 This meeting is logged and archived in a public location. 15:00:03 The chair is mkrizek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:03 The meeting name has been set to 'ansible_core_public_irc_meeting' 15:00:14 #info agenda https://github.com/ansible/community/issues/584 15:05:40 \o 15:05:41 * shertel waves 15:05:51 Sorry, got lost in all the news. :/ 15:06:28 #chair bcoca sdoran shertel 15:06:28 Current chairs: bcoca mkrizek sdoran shertel 15:06:54 #topic document the hash_behaviour=merge deprecation decision and recommended replacement 15:07:02 #link https://github.com/ansible/ansible/issues/73089 15:07:09 jerrac ^ 15:07:29 This was skipped last time due to not having enough people. 15:10:28 I think the main unresolved points from last time are: 15:10:28 1. Documenting the removal/reasoning behind it more prominently 15:10:28 2. Maybe not removing it at all 15:11:23 3. if removing, giving a pahtway that does not require full rewrite to current users 15:11:41 I knew there was one I was forgetting. Thanks. 15:12:46 3 sounds like "convert to plugin" 15:13:06 cyberpear: except taht is not possible for precedence, a vars plugin will 'mitigate' but not fix the issue 15:14:00 * bcoca considers varsmanager plugin type, 2021 has already started crazy enough that nthing is off the table 15:14:44 o.O 15:20:42 wow, did bcoca just leave everyone speechless, or did my irc client disconnect???? 15:21:07 We are all speechless. 🤯 15:21:56 sivel: I know it's your first day back, but do you have any input on the hash_merge behavior deprecation? 15:22:23 I deprecated it, that's about all I have to say 15:22:33 👍 15:22:53 that still reflects my current opinion 15:27:26 I don't see anyone commenting here in favor of reverting the deprecation. Should we just punt until next meeting? I feel like the discussion would be more beneficial if jerrac was here. 15:27:51 i would remove the deprecation if we dont have a way forward for users 15:28:00 nor really compeling reasons for the deprecation in teh first place 15:28:31 not that i've ever been for the feature, nor do i think its a good idea, but breaking user usage should only be done for compeling reasons 15:29:58 I'm in favor of removing it. I was wondering if we had more compelling reasons besides the main reason that it's hard to fully understand how very complex data will be merged. 15:30:53 sdoran: i would argue we ahve a lot of more ambiguity elsewhere that is less in use and would prioritize this at the bottom of removal list on that criteria 15:32:22 * bcoca somewhere MPD is laughing at me defending hash_behaviour 15:34:02 It seems like we should have a replacement before removing it. It's a little magical, but I'm not really against keeping it either. I don't have a strong opinion. I want varsmanager plugins now though. 15:34:36 * bcoca tries to put that geine back in bottle 15:34:56 ;P 15:36:48 I find this agreeable 15:36:53 15:37:37 I am +0 too. I would add sivel's quote for the record from https://github.com/ansible/ansible/issues/72669: "You may elect to stay on older versions of Ansible that supports the functionality you desire. Ansible 2.9 will be supported until 2023, and Ansible 2.12 may be supported until potentially 2026." which gives 5 years for users to change their playbooks if I understand it correctly. 15:41:29 is there an alternative replacement that would duplicate existing functionality? if not, perhaps it is best to not remove it. but not having been around when the deprecation was decided on, my opinion should probably matter little here. 15:43:23 Not that I know of. Users would have to rewrite playbooks. 15:43:57 but also, the person raising the objection hasn't shown up for 2 meetings now to give reasons to keep the feature, so... i am also "meh" on this, i guess 15:44:10 Yes, very specifically, we decided that it should be an explicit user decision, and there would not be a direct replacement 15:44:13 they showed up late last meeting 15:44:35 and mentioned that it was hard to make this time 15:44:36 a direct replacement would basically be the same thing as the existing implementation 15:45:00 One of my coworkers almost flipped the table when he saw the deprecation error for the first time. Not sure how much it matters, but I though I would chime in. 15:45:00 Seems like they are on west coast so maybe Tuesday would be better for them 15:46:34 Punting this until next meeting 15:46:35 #topic Open floor 15:46:46 anything else? 15:53:11 Thanks everyone. 15:53:12 #endmeeting