19:01:11 <jillr> #startmeeting Ansible Core Public IRC Meeting https://github.com/ansible/community/issues/528
19:01:11 <zodbot> Meeting started Tue Mar 17 19:01:11 2020 UTC.
19:01:11 <zodbot> This meeting is logged and archived in a public location.
19:01:11 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:11 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting_https://github.com/ansible/community/issues/528'
19:01:59 * cyberpear waves
19:02:04 * felixfontein also waves
19:02:05 <jillr> not sure if @giner is here this week?
19:02:08 <jillr> hey folks  o/
19:03:22 <jillr> I'll ping @giner in github and see if we can find out what their irc nick is
19:03:54 <jillr> cyberpear: you still looking for reviews on https://github.com/ansible/ansible/pull/65381 ?
19:04:15 <cyberpear> yes
19:04:20 <jillr> #topic https://github.com/ansible/ansible/pull/65381
19:04:44 <cyberpear> or just "get it merged" so folks can run ansible on Windows, though I understand devel is still frozen
19:05:13 <felixfontein> it's still missing a changelog fragment
19:05:36 <cyberpear> I'll ask them to add it
19:05:45 <cyberpear> (sorry, not actually my PR, just one I'd like to see progress.)
19:06:01 <jillr> jborean93: would you be able to add https://github.com/ansible/ansible/pull/65381 to your queue? relates to packaging for windows
19:06:17 <jillr> very unlikely he's online at this hour, but hopefully that can get some eyes on it
19:06:34 <jillr> thanks cyberpear
19:06:55 <jillr> #topic https://github.com/ansible/ansible/pull/66650
19:07:21 <jillr> bcoca: you wanted to make a decision on TRANSFORM_INVALID_GROUP_CHARS ?
19:07:37 <cyberpear> -1\
19:07:46 * jillr reading pr
19:08:02 <jborean93> jillr: there's not much I can do there, there's a whole bunch of other reasons why installing != using
19:08:31 <cyberpear> I've seen zero community members in support of #topic
19:08:33 <jillr> jborean93: ack, can you suggest who would be the right reviewer?
19:08:34 <jborean93> doesn't hurt to have but the decision is probably up to whoever is maintain it
19:08:44 <cyberpear> my understanding was that it come down from on high at RH support
19:08:46 <jborean93> whoever is in charge of releases
19:09:05 <jillr> kk
19:09:12 <felixfontein> I added a review
19:09:29 <cyberpear> there's a really long thread w/ folks decrying the TRANSFORM_INVALID_GROUP_CHARS if anyone really wants to see all the opposition
19:09:46 <felixfontein> oh, already next PR
19:10:04 <felixfontein> many people like having - in group names, in particular
19:10:06 <cyberpear> (not my topic, but I do have strong feelings on it)
19:10:11 <cyberpear> also dots
19:10:15 <jillr> thanks felixfontein, apologies I didnt think there were any other cores around so moved ahead
19:10:47 <felixfontein> jillr: no problem, Windows also isn't anything I'm using, and I got carried away a bit when researching os.path
19:11:13 <felixfontein> cyberpear: hmm, I never used dots in groups, but I guess people also want to use that (like use domain name with TLD as a group)
19:11:34 <cyberpear> exactly: TLD stg.example.com, dev.example.com, etc
19:12:00 <jborean93> my personal belief is if someone wants to shoot themselves in the foot just let them but I have no sway on this decision
19:12:17 <felixfontein> I don't mind re-allowing them (even though I already removed all uses of "-" in our group names)
19:13:18 <felixfontein> I don't know how many support requests arrived because people tried to do stuff like `groups.my-group` in a template
19:13:54 <felixfontein> I think that was the main (or even only?) motivation to disallow everything that makes a group name not a Python identifier
19:14:25 <felixfontein> I have seen a lot more people complain about this change than support requests because people did things wrong. but I'm also biased :)
19:14:38 <jborean93> yea a big drive was doing just that wouldn't work and you had to do `{{ groups['my-group'] }}`
19:15:22 <felixfontein> jborean93: do you know how often people had problems because of that?
19:15:37 <cyberpear> I mean, why not forbid it in inventory_hostname because `hostvars.my-host` is bad, too?
19:15:40 <sivel> I've got to say, that brining this topic up all the time isn't a good use of time
19:15:52 <cyberpear> bcoca nominated it
19:16:07 <felixfontein> I think the aim was to solve this once and for all (like, again :) )
19:16:29 <cyberpear> since bcoca is not here, move on to next topic?
19:16:34 <sivel> honestly, I don't think this is going to be the right forum to make a decision on this
19:16:45 <jillr> +2 moving on
19:16:47 <cyberpear> sivel: what's the correct forum?
19:16:55 <felixfontein> sivel: what is the right forum for making that decision?
19:17:02 <cyberpear> "declaration from Red Hat On High"?
19:17:15 <sivel> I'm going to abstain on that, but this project is not a democracy
19:17:16 <cyberpear> -1 to "declaration from Red Hat On High"
19:17:24 <sivel> too many cooks in the kitchen distract
19:17:45 <sivel> We know the arguments at this point
19:17:59 <sivel> anywho, next topic
19:18:02 <felixfontein> I'm happy with any decision as long as the option stays and people can enable both settings without deprecation warnings
19:18:08 <jillr> #topic https://github.com/ansible/ansible/pull/68177
19:18:26 <felixfontein> this is about deprecation in collections, mainly
19:18:38 <cyberpear> on the "deprecate by date" idea, my only concern is that users not see a different deprecation warning from the same code based on thedate
19:18:51 <cyberpear> so maybe "deprecated by date of release"
19:19:02 <felixfontein> it allows modules to declare that an option or alias is deprecated and will be removed at a date, as opposed to at a version (which is confusing if it's unclear *which* version)
19:19:38 <felixfontein> (*which* version => version of *what*)
19:19:38 <sivel> I'm in favor of this, I see no issues with it.  I think we're going to just need more eyes on it, which I understand is the goal here, but were are of short on participation due to other things that are going on
19:19:57 <cyberpear> so maybe, it should say something like "this module will be removed in any releases of this collection made after date 2020-03-16"
19:20:13 <felixfontein> cyberpear: I don't mind changing messages or something, my main purpose is that this should get implemented not too far in the future :)
19:20:25 <sivel> It should attempt to stay consistent with what is in https://github.com/ansible/ansible/pull/67684
19:20:41 <felixfontein> also, I'd vote for backporting a change like this to stable-2.9, to allow collections to start using this form *now* instead of having to wait until Ansible 2.10 is out and everyone uses it
19:20:50 <sivel> so don't run down the path on one, without making sure the other is in sync
19:21:19 <sivel> https://github.com/ansible/ansible/pull/67684/files#diff-cb51550dcfdbd27a3f224be2de15e2e8R137
19:21:23 <felixfontein> (I really need to look at that PR in more detail, I didn't really have time yet)
19:22:37 <felixfontein> that link doesn't probably work because GitHub folds the changes in loader.py away
19:22:50 <felixfontein> (i.e. unfold that to see where it really points to)
19:23:15 <cyberpear> felixfontein: yeah, I missed that... looks fine
19:24:23 <felixfontein> does anyone mind making sure that dates are in ISO format (i.e. YYYY-MM-DD)?
19:25:03 <jillr> extremely +1 ISO format please
19:25:28 <felixfontein> I don't want to end up where a zoo of different date formats is used everywhere
19:26:08 <jillr> I'd alternatively accept discordian dates, but only those 2 options  ;)
19:26:09 <sivel> felixfontein: I'd recommend talking with nitzmahone about that as well.  We discussed it, and had originally decided to 1) not validate it, 2) not parse it
19:26:27 <sivel> leaving it effectively as free form
19:26:44 <felixfontein> hmm, do you remember *why* you decided for that?
19:26:45 <nitzmahone> My samples and tests were definitely ISO format though :)
19:27:03 <jborean93> ISO all the way
19:27:03 <sivel> I could be convinced on validation that it meets a format, but maybe not that it adheres to a future date
19:27:09 <tremble> If you don't pick a format there will be confusion.
19:27:16 <felixfontein> enforcing ISO makes sure that this can easily be parsed by callback plugins and represented in whatever format people want
19:27:25 <nitzmahone> I'm not opposed to validating that, because I'm hoping we can use those to drive "it's time to remove X" decisions during release planning as well
19:27:48 <nitzmahone> But I'd also rather not be validating at runtime
19:28:04 <tremble> nitzmahone, Sanity test check?
19:28:20 <felixfontein> the problem is that right now, validation of deprecation versions and dates is completely disabled
19:28:35 <felixfontein> that's the next topic on the agenda (https://github.com/ansible/ansible/pull/66920) ;)
19:28:36 <nitzmahone> +1 to that, I assume we'll want that anyway, but it has to get finalized first :)
19:28:47 <jillr> So, generally this is a good idea but it needs reviews, please keep 67684 (tombstoning) in mind, maybe talk to nitz about date formats/validation, and please backport once accepted.
19:29:04 <felixfontein> sounds good :)
19:29:14 <felixfontein> does this need another discussion for backporting?
19:29:37 <jillr> I imagine that can happen in the backport PR?
19:30:34 <felixfontein> I mainly mean, do we want such a feature (even if it is different from this implementation) to be backported?
19:31:41 <sivel> felixfontein: I think only ansible-deprecated-version is disabled, both ansible-deprecated-no-version and ansible-invalid-deprecated-version are enabled
19:31:59 <sivel> so I think we can validate it via CI/sanity
19:32:28 <felixfontein> sivel: ah, true
19:33:13 <felixfontein> sivel: so I guess the question of the next agenda item is whether to validate the removal version resp. date
19:33:54 <jillr> #topic https://github.com/ansible/ansible/pull/66920
19:34:00 <sivel> felixfontein: it could be added, but disabled like it is. Otherwise it would start failing without someone taking explicit action
19:34:49 <felixfontein> but if it is disabled, essentially nobody will enable it, and a lot of people will not notice that stuff should be removed (or have been removed some time ago)
19:35:04 <sivel> felixfontein: yeah, I suppose it could be a per collection decision
19:35:42 <tremble> It really needs to be a non-voting failure.  It's run, it's visible, but it shouldn't block unrelated changes.
19:36:01 <felixfontein> tremble: yes, that would be great
19:37:08 <felixfontein> is there a mechanism in ansible-test to have failures which don't break everything?
19:37:14 <felixfontein> s/break/block/
19:39:09 <sivel> no
19:39:46 <sivel> not that I know of. It was talked about for the mccabe testing, but I don't think such a feature exists
19:41:30 <felixfontein> it would be nice to have that eventually
19:42:09 <jillr> sivel: that's a shippable limitation, not anisble-test, right?
19:42:21 <sivel> jillr: unknown
19:42:28 <jillr> zuul supports non-voting tests, and we have several collections there
19:42:34 <felixfontein> is there a way to disable certain tests in validate-modules?
19:42:37 <sivel> I mean ansible-test has nothing for it, whether that is a shippable limitation or not
19:42:46 <sivel> felixfontein: no, just ignores
19:43:04 <jillr> Goneri: do you know if we're currently using non-voting tests in zuul yet? or do you know anything relevant about^
19:43:11 <felixfontein> hmm, too bad
19:43:42 <felixfontein> it would be nice if it would be possible to enable (or disable) removal version checking somehow
19:44:00 <Goneri> well, we can turn non-voting any Zuul job.
19:44:43 <jillr> so if we added the tests proposed in https://github.com/ansible/ansible/pull/66920 as disabled by default, we could at least enable them for network and vmware collections
19:44:58 <jillr> would there be value in that?
19:45:43 <bcoca> not sure if we should remove those, or have a switch that skips them, there are still plugins in core that might want to keep current methods
19:47:26 <felixfontein> bcoca: you can always use ignore.txt for specific places which should be kept
19:48:30 <bcoca> unsure how that works, if you remove the test, there is no ignore to do ....
19:48:54 <bcoca> was saying 'switch' as collections would not have same reqs as core
19:49:13 <bcoca> that way we can add things to both sides and still share most of the utility/code
19:49:19 <tremble> Alternatively, have a bot that opens issues...
19:50:04 <felixfontein> bcoca: do you mean plugins for ansible-test, or ansible plugins? I'm not really sure what you meant with 'keep current methods'
19:50:06 <jillr> ok so, what's the specific thing that needs to be decided for this PR? whether it has an adequete mechanism for enable/disable?
19:50:38 <jillr> or whether CI can handle it's output sanely?
19:50:41 <felixfontein> I guess it needs a way to explicitly enable this then (without having to edit internals of ansible-test)
19:52:27 <jillr> does anyone disagree with^, or have a differing view of what needs to happen next?
19:52:47 <felixfontein> it would be really good if it is possible to run ansible-test with these tests enabled, so that ansible-base and collections can use it to find such removals when they want
19:53:16 <felixfontein> (being able to have warnings in CI would be even better, but that requires bigger changes to ansible-test itself I guess)
19:54:03 <jillr> felixfontein: do you have what you need to move forward?
19:54:11 <felixfontein> I think so, if nobody disagrees :)
19:54:19 <bcoca> ansible plugins
19:54:34 <jillr> ?
19:54:47 <bcoca> sorry, juggling 4 things, response to prev question to me
19:54:49 <jillr> oh sorry, I missed you were replying to felix's question above
19:54:53 <jillr> no worries
19:55:17 * bcoca now konws what happens when he even gives a hint of having extra bandwith
19:55:22 <felixfontein> :D
19:55:28 <felixfontein> you only found that out now?
19:55:34 <jillr> I think that's everything then - thanks folks!
19:55:41 <jillr> #endmeeting