19:01:08 <nitzmahone> #startmeeting Ansible Core Public IRC Meeting
19:01:09 <zodbot> Meeting started Tue Oct 27 19:01:08 2020 UTC.
19:01:09 <zodbot> This meeting is logged and archived in a public location.
19:01:09 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:09 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:01:14 <sdoran> \o
19:01:20 <nitzmahone> #chair jborean93
19:01:20 <zodbot> Current chairs: jborean93 nitzmahone
19:01:23 <cyberpear> o/
19:01:26 <jborean93> yo
19:01:43 <nitzmahone> Looks like the only item on today's agenda has already been merged
19:02:07 <nitzmahone> We'll give it a minute to see who else is around
19:02:54 <nitzmahone> #topic chaos naming
19:03:12 <felixfontein> hi!
19:04:10 <bcoca> naming is chaos!
19:04:18 <felixfontein> it always is
19:04:23 <nitzmahone> For those who weren't at contrib summit, one of the things we're working on is an integration branch for Ansible that we've been calling Ansible Chaos (working title). Basically it's a way for us to have a side-by-side installable occasional release of Ansible to let users play with experiemental features and seek feedback, then blow away and start over with a different set of features
19:04:38 <bcoca> 'lab'
19:04:41 <bcoca> 'proto'
19:04:43 <bcoca> 'yolo'
19:04:48 <sdoran> 'working-title'
19:05:12 <felixfontein> nitzmahone: btw, https://github.com/ansible/ansible/pull/71734 is still open from last week
19:05:13 <nitzmahone> We thought we'd seek ideas from the community about what it should be called
19:06:05 <bcoca> 'play mcplayface' and most variants are already taken
19:06:14 <nitzmahone> A few candidates so far: `ansible-bikeshed`, `unsible`
19:06:23 <bcoca> 'usable'
19:06:27 * shertel waves
19:06:48 <felixfontein> ansible-kindergarden? for PRs to grow up? :)
19:06:49 <jborean93> `ansible-failbook`
19:07:06 <nitzmahone> I'm hoping to find a single short-ish word like `ansible` that can imply its connection to Ansible and the fact that it's experimental (since it can be installed SxS, by default it won't take over the `ansible-X` entrypoints)
19:07:24 <felixfontein> antsibull is already taken :)
19:07:27 <bcoca> dragon .. not just the enders ref for a team but 'here be dragons'
19:07:42 <bcoca> drgn
19:07:52 <nitzmahone> felixfontein: (and incredibly confusing when spoken out loud since it's a homophone of "ansible" ;) )
19:08:09 <felixfontein> nitzmahone: true :) that's one of the reasons it was picked ;)
19:08:11 <bcoca> ansibull
19:08:54 <jborean93> `formic`
19:09:10 <sdoran> 'kuso'
19:09:28 <felixfontein> antsible
19:09:36 <nitzmahone> So anyway, just something to think about- we'll probably bring it up at another meeting or two before we set something in stone, so if you've got a fantastic idea for a name, speak soon or forever hold your peace ;)
19:09:44 <nitzmahone> sdoran :D
19:10:12 <felixfontein> trysible
19:10:13 <nitzmahone> If it weren't so long, I'd think about co-opting sivel's `toiletwater` :D
19:10:33 <bcoca> attemptible
19:10:40 <sivel> lol
19:10:54 <nitzmahone> Since his descriptive text for it will also apply to ansible-chaos: "You might be able to drink it in an emergency, but you might still die"
19:11:00 <sivel> lol
19:11:26 <mattclay> ansivel ;)
19:11:32 <sivel> :boom:
19:11:33 <felixfontein> hehe
19:11:38 <bcoca> mattclay++100k
19:12:01 <nitzmahone> Anyway, just a background task- shout out ideas whenever in the next few days if they come to you, and if we see anything we love and end up using, we'll give you a prize  of some sort
19:12:47 <aminvakil> ansibeta ansibleta
19:12:48 <nitzmahone> felixfontein: anything about  https://github.com/ansible/ansible/pull/71734  needing discussion here, or just awaiting review/bikeshedding?
19:15:18 <felixfontein> nitzmahone: from my pov it doesn't need discussion, so I guess reviewing/bikeshedding?
19:15:55 <nitzmahone> Cool- we'll take a looik
19:15:57 <nitzmahone> *look
19:16:01 <nitzmahone> #topic open floor
19:16:55 <nitzmahone> #action core team to review  https://github.com/ansible/ansible/pull/71734
19:17:32 <nitzmahone> If nothing for open floor, we'll close in 2min
19:17:52 <felixfontein> maybe a question about required_by :)
19:18:05 <nitzmahone> go ahead
19:18:19 <felixfontein> currently required_by behaves differently than all other required* conditions, and different from mutually_exclusive, since it treats an explicit specified `None` the same as not specified at all
19:18:49 <felixfontein> neither mutually_exclusive, nor all other required* tests do that, for them an explicitly specified `None` counts as 'is specified'
19:19:19 <felixfontein> is there a chance to eventually change that? :)
19:20:08 <nitzmahone> consistency is usually a Good Thing IMO, so unless there's a great reason that's not immediately obvious NOT to change it, I don't see why now
19:20:10 <nitzmahone> *not
19:20:16 <felixfontein> especially when required_by is combined with other required* statements, this could be very confusing (next to the whole None business)
19:20:36 <felixfontein> I guess the main argument against changing it is that it has been like that for a long time
19:20:53 <felixfontein> (but same is true for required* and None handling)
19:21:00 <jborean93> AFAIK required_by is one of the newer ones
19:21:03 <nitzmahone> Has it though? Isn't that the new one that just got added recently?
19:21:05 <nitzmahone> yeah
19:21:07 <shertel> doesn't required_if behave the same way with None options?
19:21:20 <jborean93> I believe dag added it in 2.7/8 or something
19:21:30 <felixfontein> shertel: no, required_if uses `in`, and not `in` + `is None`
19:21:58 <felixfontein> (TBH I have no idea when required_by was added)
19:22:10 <nitzmahone> I thought it might've even been new for 2.9
19:22:21 <nitzmahone> But everything blurs together
19:22:26 <felixfontein> cd9471ef17c985006c7d77687030890003cf395d, Fri Feb 15 01:57:45 2019 +0100
19:22:39 <nitzmahone> OK, so 2.8
19:23:30 <felixfontein> yep, 2.8.0 is the first release tag it showed up in
19:24:52 <nitzmahone> felixfontein: can you file an issue for that and CC me on it? That seems like pretty low-hanging fruit for 2.11 at least (if not backports)
19:26:36 <felixfontein> I already deprecated it in https://github.com/ansible/ansible/pull/72248 (the first iteration of that PR simply changed its behavior, but I guess that's not a good idea)
19:27:35 <nitzmahone> ah ok, cool, so the desired behavior is already implemented there, right?
19:27:53 <nitzmahone> (well, warned about)
19:28:08 <felixfontein> if 'deprecate the old behavior' is desired, then yes
19:28:40 <felixfontein> (right now it's a deprecation warning, removal in 2.15, but I can change it to a regular warning)
19:28:43 <nitzmahone> Yeah, probably so, even though that one is so rarely used we could probably get away with just changing it... But yeah, deprecation is probably the more kosher path
19:29:29 <nitzmahone> OK, anything else for today?
19:29:30 <felixfontein> I asked sdoran earlier about this, and he suggested to not deprecate it
19:30:04 <nitzmahone> as in "just change it" ? For that one, I could live with that as well...
19:30:04 <felixfontein> I thought some more about it, but I still think it should be deprecated, that's why I'm asking here
19:30:29 <felixfontein> I think as in "keep it"
19:30:34 <nitzmahone> Yeah, it's so new and corner-case-of-corner-case that straight change is *probably* fine, but hard to know for sure
19:30:58 <sdoran> I don't feel like debating it more. We can deprecate it.
19:31:06 <nitzmahone> IMO one way or another we should fix it or move toward fixing it
19:31:21 <sdoran> If it breaks folks, I'll just point them to Felix. 😉
19:31:29 <nitzmahone> (as I'm pretty sure the inconsistency was an oversight, not on purpose)
19:31:32 <felixfontein> do you prefer first adding a warning, and then changing that to a deprecation in 2.12? or right away deprecating it?
19:31:58 <sivel> my opinion is we should work toward deprecating all of the required_*, mutually_* keywords :) and give users a better system for validation
19:32:05 <felixfontein> sdoran: fine :P
19:32:24 <nitzmahone> sivel: just as we're setting the existing stuff in more concrete with role argspec :(
19:32:54 <sivel> those required_* methods are nearly unreadable. Without looking at the implementation, I never know what they do
19:33:08 <nitzmahone> Agreed, the UI for them is ... not great
19:33:08 <sivel> just my 2c if we're offering opinions ;)
19:33:10 <felixfontein> sivel: I wrote docs! https://github.com/ansible/ansible/pull/72335
19:33:21 <sivel> felixfontein: no one reads docs :)
19:33:25 <felixfontein> (I had the same problem for a long time, especially for required_by)
19:33:32 <nitzmahone> "OK, so for this one I need a doubly-nested tuple, and for that one I need some kind of moebius strip"
19:34:51 <sivel> nitzmahone: but you have a point, moving to a more code based validator, doesn't help role arg specs if they are defined in pure YAML
19:35:18 <nitzmahone> felixfontein: to your original question- so long as the way to fix it is available, it's a small enough corner case that I'd say go ahead and deprecate immediately
19:35:48 <felixfontein> nitzmahone: the fix would be to adjust user roles and playbooks
19:36:04 <bcoca> sivel: depends at one point the plugin/module author will have to do very specific validations, these are mostly 'common and convienient' ones
19:36:40 <jborean93> felixfontein: there's more docs in the windows module dev, might be good to try and unify it in 1 location
19:36:41 <Shrews> fwiw, there are no plans to support the required_* or mutually_* things in role argspec at this time
19:36:43 <felixfontein> a lot of modules already do validations, and quite some percentage can be replaced with the current mechanisms. well, at least if that None quirk is gone :)
19:36:50 <nitzmahone> There's also no reason we can't extend the role argspec (etc) to support collection-hosted callable validators
19:37:15 <nitzmahone> "don't like what we provide? Dust off your Python and knock yourself out."
19:37:19 <bcoca> whole reason to codify as action is to allow for that
19:38:23 <nitzmahone> Well, not the whole reason, but definitely "a reason"- but I meant being able to invoke a custom validator from the YAML declaration (eg for a type or the whole thing), though that's potentially another can of worms
19:38:41 <bcoca> he, yes, 'a'
19:39:00 <nitzmahone> Like we already support passing callables for type validation at runtime, so just supporting the ability to reference a callable as a collection resource
19:39:31 <nitzmahone> (and for bonus points, an additive or replace-a-tive validator for the whole thing- a couple folks asked for that)
19:39:54 <bcoca> well, you get that by overriding the action
19:39:55 <nitzmahone> My initial answer to the latter was "write your own validator action then"
19:39:58 <nitzmahone> yeah
19:40:17 <bcoca> also, we already have a couple of them in 'the wild' .. see networking
19:40:59 <nitzmahone> Anyway...
19:41:24 <nitzmahone> Closing in 2 unless there's anything more...
19:41:36 <felixfontein> some basic validation like required, mutually_exclusive, required_* would definitely be nice for roles though
19:41:44 <nitzmahone> Yep, it's there
19:42:01 <felixfontein> 20:36 <@Shrews> fwiw, there are no plans to support the required_* or mutually_* things in role argspec at this time
19:42:07 <cyberpear> Is "stableinterface" still a thing in a collections world?  i.e., for modules in ansible-base, are some still "preview"?
19:42:08 <nitzmahone> oh
19:42:24 <felixfontein> cyberpear: both stableinterface and preview are gone
19:42:24 <nitzmahone> I could've sworn they were there in the original spec, but maybe I'm stale :)
19:43:03 <felixfontein> cyberpear: there's bcoca's proposal https://github.com/ansible/proposals/issues/68 which would re-add them in a better way (and a lot more)
19:43:08 <sivel> we nuked ANSIBLE_METADATA in 2.10
19:43:27 <Shrews> @nitzmahone we decided against that in the initial implementation
19:43:45 <nitzmahone> Yeah, I know the UI was problematic for those
19:44:16 <bcoca> cyberpear: those were mostly 'core contracts' once we moved to collecitons, its up to each collection to specify state
19:45:00 <bcoca> Shrews: i had some of them worked out, but only the simpler ones
19:45:04 <cyberpear> thanks for the proposal link
19:46:21 <nitzmahone> #action felixfontein to update 72248 to deprecate None-is-unspecified behavior in required_by
19:46:41 <felixfontein> nitzmahone: the PR is currently deprecating it
19:46:41 <bcoca> Shrews: mostly keywords requires/depends/conflicts
19:46:57 * nitzmahone apparently can't read today
19:46:59 <nitzmahone> #undo
19:46:59 <zodbot> Removing item from minutes: ACTION by nitzmahone at 19:46:21 : felixfontein to update 72248 to deprecate None-is-unspecified behavior in required_by
19:47:22 <nitzmahone> OK, before I cause any more trouble, let's call it a meeting then ;)
19:47:27 <nitzmahone> #endmeeting