19:05:16 <bcoca> #startmeeting ansible core irc public meeting
19:05:16 <zodbot> Meeting started Tue Mar 19 19:05:16 2019 UTC.
19:05:16 <zodbot> This meeting is logged and archived in a public location.
19:05:16 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:05:16 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:05:45 <bcoca> #topic https://github.com/ansible/ansible/pull/32214
19:05:56 <bcoca> @akasurde?
19:06:13 <jtanner> we can test that, right?
19:06:35 <bcoca> we do have os x targets
19:07:01 <jtanner> i would request tests then
19:07:01 * bcoca wonders about vanity plates for jtanner with 'havetests?'
19:07:14 <jtanner> i tattooed it to my forehead
19:07:49 <sdoran> Weird. I don't see an integration target for `hostname`.
19:07:57 <bcoca> we probably never had one
19:08:05 <sdoran> Should be pretty easy to write tests, though.
19:08:13 <bcoca> sdoran: thansk for volunteering
19:08:20 <bcoca> ;-p
19:08:37 <sdoran> I think the main discussion on that one was whether to change one or all three "names" when setting hostname.
19:08:45 <sdoran> bcoca: I have a bad habit of doing that. :)
19:09:06 <sdoran> I think it got dialed back, though.
19:09:18 <bcoca> idk enough about implications of each location for OS X
19:09:27 <sdoran> To only set the host name and not the other names.
19:09:35 <sdoran> It makes most sense to change all three, IMO.
19:09:48 <sdoran> But I say we start with only setting one and expand in the future.
19:10:03 <sdoran> I'm assigned to that one. Been meaning to test it out.
19:10:20 <bcoca> #topic https://github.com/ansible/ansible/issues/52354#issue-410909935
19:10:27 <bcoca> i thought we had discussed this alraedy
19:10:37 <bcoca> using XDG spec for ansible dirs
19:10:53 <ju2wheels> not sure if things are following a designated order, but for the end, if possible looking for feedback on #49000 and #50829 or can come back next meeting if I needed to add these to an agenda before hand
19:10:53 <sivel> we declined, but the author added it to the agenda
19:10:56 <bcoca> -1 since its linux only spec, and not all distros comply with it
19:11:12 <sivel> I am -1 just because of the unnecessary added complexity
19:11:19 <sdoran> -1 for all the above
19:11:25 <bcoca> ju2wheels: add to agenda
19:11:45 <bcoca> he, complexity makes it -10k for me
19:12:24 <bcoca> @c-edw ? @cedwards ?
19:13:07 <bcoca> hmm user absent but knowing most commiters, i see little chance of reversal here, going to close it out and can be brought up again if some VERY convincing argument is produced
19:13:19 <bcoca> #topic https://github.com/ansible/community/issues/436#issuecomment-465655663
19:13:25 <bcoca> force lowercasing choices
19:13:49 <bcoca> -1 i don think its a common case, but authors might need a meaningful disctinction
19:13:50 <sivel> I thought nitzmahone decided to not pursue that
19:14:03 <nitzmahone> puntarooni
19:14:04 <bcoca> +1 to creating an istr type for 'case insensitive'
19:14:17 <bcoca> k, so abandoned?
19:14:27 <sivel> yes
19:14:30 <jborean93> does that mean we want to remove the ps deprecation warning?
19:14:34 <nitzmahone> for now, probably will be something like a separate type
19:14:43 <bcoca> +1 for sep type
19:14:44 <nitzmahone> jborean93: yeah, probably
19:14:59 <jborean93> ok
19:15:04 <bcoca> #topic https://github.com/ansible/ansible/pull/51466#pullrequestreview-209973452
19:15:10 <bcoca> another i thought we voted against
19:15:20 <bcoca> @abedwardsw?
19:15:34 <bcoca> @jamescassell
19:15:43 <cyberpear> hi
19:15:53 <cyberpear> the dict() suggestion doesn't work on rhel7
19:16:02 <cyberpear> any chance of getting a dict filter, or a newer jinja?
19:16:04 <bcoca> waht about the dict lookup?
19:16:22 <bcoca> cyberpear:  we dont restrict jinja2 versions on ansible side
19:16:26 <nitzmahone> we should just conditionally plug the dict filter in
19:16:40 <bcoca> nitzmahone: dict() is global, not filter
19:16:40 <nitzmahone> (if J2 version is < 2.8)
19:16:58 <bcoca> if we add filter (i do have code) no need to be conditional
19:17:12 <cyberpear> bcoca: had a local to_dict filter that wasn't in ansible, but on F29 version of jinja2, you can dict(mything) and it works fine
19:17:47 <cyberpear> bcoca: would you be opposed to adding your code?
19:18:09 <bcoca> https://github.com/ansible/ansible/pull/53488
19:18:12 <bcoca> nope
19:18:13 <sivel> as a tangential discussion, I would prefer that we didn't create a filter named `dict`
19:18:25 <sivel> just to avoid confusion with name overlap
19:18:31 <bcoca> to_dict
19:18:31 <cyberpear> we already have one called 'list'...
19:18:34 <jtanner> what does "to_dict" do?
19:18:43 <bcoca> turns 'list of pairs' into a dict
19:18:57 <jtanner> like dict(<tuple>) would do?
19:18:58 <sivel> cyberpear: that is provided by jinja2, and there is no |list filter
19:19:02 <bcoca> same as dict((a,b)) == x[a] = b
19:19:04 <cyberpear> ah
19:19:19 <sivel> jtanner: yes, it is literally the exposed `dict` constructor
19:19:22 <cyberpear> in my opinion, the intermediate state should be just a dict, but that's a jinja feature, I think
19:19:23 <jtanner> k
19:19:45 <bcoca> i had it cause i was unware of global dict() function
19:19:47 <sivel> pre jinja2 2.8 it was some weird lambda that only accepted key=value pairs
19:20:13 <sivel> some jinja magic could likely make that work though
19:21:13 <sivel> dict(*((myvars | zip(lookup('vars', *myvars)))|map('join', '=')|list))
19:21:17 <sivel> something like that
19:21:22 <sivel> or not
19:21:24 <sivel> who knows
19:22:28 <sivel> I'm not opposed to adding some compat code.
19:22:55 <cyberpear> I'd be very happy to have the compat code...
19:23:01 <jtanner> if it gets that ugly, might as well drop something into filter_plugins and save yourself headache
19:23:20 <bcoca> ^ my pr above, but we might just want to remove |dict and only have |to_dict
19:23:31 <bcoca> but ... having |list ...
19:23:39 <abadger1999_> or monkeypatch the old jinja2's dict function.
19:23:54 <sivel> I'm kindof thinking the same as abadger
19:24:05 <sivel> it's super easy to just overwrite the dict global
19:24:07 <bcoca> at least im not one saying it ...
19:24:11 <bcoca> yep
19:24:23 <abadger1999_> otherwise we end up maintaining a filter that duplicates jinja2 functionality in the future.
19:24:29 <bcoca> agreed
19:24:34 <sivel> and we don't even need a version comparison, we could just do it unconditonally
19:24:43 <bcoca> so it 'always works'
19:24:50 <sivel> this was the jinja2 commit: https://github.com/pallets/jinja/commit/6179c02
19:24:53 <cyberpear> working the same way everywhere is good
19:24:54 <bcoca> but might be an issue if jinja2 introduces chagnes in future
19:25:14 <nitzmahone> (or not, so that way we're always presenting the same behavior everywhere)
19:25:31 <sivel> cross that bridge when we get there
19:25:37 <nitzmahone> I've always hated the "ohhh, sorry, X isn't going to work because your distro's jinja is dumg"
19:25:40 <nitzmahone> *dumb
19:25:57 <bcoca> k, we seem to have agreement, monkey patch dict()
19:26:31 <cyberpear> +1
19:26:42 <nitzmahone> yeah, so long as we can augment the existing behavior without breaking (eg in case people are using in "full" templates or something)
19:27:12 <bcoca> https://gist.github.com/bcoca/66420572df56325eacd523869250f70d
19:27:13 <sivel> nitzmahone: it won't break. the real dict constructor implements the functionality the old lambda did
19:27:26 <sivel> just adds more functionality on top
19:27:43 <nitzmahone> cool
19:28:01 <cyberpear> that's an easy-looking patch...
19:28:47 <bcoca> its not like i had it ready and was waiting for someone else to mention 'monkey patch'
19:28:54 <sivel> haha
19:29:20 <bcoca> https://github.com/ansible/ansible/pull/54057
19:30:00 <bcoca> #topic https://github.com/ansible/community/issues/450#issuecomment-469838337
19:30:18 <nitzmahone> +1 for _info
19:30:27 <bcoca> naming convention for  'non fact modules' since we decided not to allow _facts in those cases
19:30:30 <bcoca> +1 for _info
19:30:54 <sivel> I am fine with _info, I had wanted to say _info if there was an associated non-info module too, but that makes the guideline too complex
19:31:08 <cyberpear> `_info` sounds good to me
19:31:29 <sivel> so +1 to _info
19:31:32 <nitzmahone> Sounds like a 2.9 project to alias/symlink
19:31:40 <bcoca> and deprecate
19:31:50 <sivel> tag, you're it
19:31:52 <bcoca> also update 'module checklist'
19:31:57 <bcoca> i'll update the docs
19:32:01 <sdoran> +1 for _info suffix
19:32:14 <bcoca> @felixfontein any objections?
19:32:31 <bcoca> comments, other suffixes ? otherwise _info it is in 1 min
19:33:19 <bcoca> _info wins in landslide, i'll update module guidelines, we'll have to open project to properly name/rename exisitng violators
19:33:29 <bcoca> #topic https://github.com/ansible/ansible/pull/45805
19:34:16 <bcoca> hmm -1 cause it still requires 'dual' origin, but +1 to the fact that there is a lot less dupe data
19:34:21 <sivel> At current the module_args.py file from validate-modules no longer depends on mock, it just monkeypatches directly, instead of having mock do it
19:34:35 <sivel> but in the end I am meh
19:35:01 <bcoca> it doesnt have suboptions .. so really -1 @gundalow this does not seem ready to merge
19:35:10 <bcoca> also breaks ansible-doc
19:35:53 <bcoca> hmm he is at londong meetup, i'll ask what he wanted here, this seems FAR from ready
19:36:22 <nitzmahone> Also Windows
19:37:00 <gundalow> Hey
19:37:00 <sdoran> I understand the notion behind this, but I don't know if it's a good idea.
19:37:12 <gundalow> 45805?
19:37:16 <sdoran> Yes
19:37:40 <gundalow> Ah, I should have added words.
19:37:41 <bcoca> @drzaf ?
19:37:54 <gundalow> Basically do we want this, is the idea sensible?
19:38:02 <sdoran> We do have a different behavior between plugins and modules IRT docs being the source of truth.
19:38:10 <gundalow> Before we get into technical discussions on implementation
19:38:23 <bcoca> well, plugins dont have 2 sources, only modules do
19:38:36 <sdoran> Right.
19:38:37 <gundalow> Today we don't have validations of Plugins docs
19:38:40 <sivel> nitzmahone: module_args.py supports windows now, but only for the csharp Ansible.Basic based modules
19:38:49 <bcoca> modules have args_spec dict + docs in DOCUMENTATION, plugins rely on single source for both
19:38:55 <jborean93> and requires .NET/PowerShell Core to be instaled
19:39:07 <sivel> jborean93: ah yeah, good point
19:39:09 <nitzmahone> noice
19:39:10 <sivel> forgot about that
19:39:42 <sivel> I'm still meh
19:40:23 <nitzmahone> Same, it's kind of a half measure; nice to get rid of the duplication, but ...
19:40:32 <sdoran> I'm gonna just go with -1.
19:40:56 <bcoca> +1 to intent, but -1 to implementation
19:40:59 <sivel> in a way I think the duplication is a benefit, as it helps validate the intent
19:41:12 <sdoran> It'd be nice to leverage DOCUMENTATION to reduce data duplication, but it creates more problems than it solves.
19:41:25 <nitzmahone> *cough* sidecar *cough*
19:41:35 <bcoca> sivel: yes and no, it also creates a maintenance burden and ends up diverging in many cases, validate-modules does help us a lot in that respect, but not for 3rd party
19:42:11 <bcoca> nitzmahone: lookeing at that, cannot see it used for docs, only for type hints, do you have example pyi with docstrings that can be used instead of main file ?
19:42:30 <gundalow> A) Is this something we'd want to solve like this, or take a step back and attack differently
19:42:43 <sivel> I have no idea what sidecar is
19:42:48 <sivel> well, in this context
19:43:03 <bcoca> gundalow: afaik there are 2 ways to solve, it, ends up being same but diff source, a) unify all in docs and build arspec from that b) unify in argspec and build docs from that
19:43:11 <bcoca> sivel: pyi files
19:43:42 <bcoca> from pep484 (type defs that can live in files adjacent to actual code files)
19:44:08 <bcoca> nitzmahone  was just telling me they can be used for docstring docs (avoid shipping them with module_utils but still build api docs for users)
19:44:11 <gundalow> This (or similar) has been thrown around every so often for the past few years. I'd love us to say "by Ansible 2.11 we will ensure all modules are written in way x"
19:44:35 <bcoca> gundalow: its been a project for 'the next release'  ... since 1.6
19:44:44 <sivel> users don't read docs anyway ;)
19:44:54 <bcoca> iirc sdoran was last one trying to do this in 2.6?
19:45:19 <bcoca> sivel: no, but its nice to have something to point at when they ask stuff
19:45:21 <jborean93> if you want something universal you would have to have the docs shipped over as a separate meta like json
19:45:31 <jborean93> it can't be Python specific
19:45:32 <sivel> bcoca: I'm just messing
19:45:39 <bcoca> jborean93: why current ones are yaml
19:45:55 <bcoca> sivel:  you are only 1/2 messing ...
19:45:59 <sdoran> bcoca: What was I trying to do in 2.6?
19:46:00 <sivel> haha
19:46:03 <jborean93> yea but we would need a mechanism to store that alongside our existing modules
19:46:10 <sivel> sdoran: something bad I imagine :p
19:46:12 <bcoca> sdoran: unified argspec and docs fro modules
19:46:24 <bcoca> and allow 'controller side args spec' reading
19:46:24 <jborean93> then have basic.py and the ps equivalent to be able to parse that
19:46:34 <sdoran> I think that is something I _did not_ volunteer for. :)
19:46:45 <bcoca> sdoran: or the pain is blocking the memory
19:47:13 <sdoran> Could be. I've been neck deep in arg spec stuff for too long...
19:47:35 <sivel> I'm not sure we are going to get more out of this topic
19:47:52 <bcoca> oh, plenty more .. but i dont think it would be useful ...
19:48:10 <sivel> sure, I left out the classification
19:48:19 * nitzmahone ducks incoming cherry pie from the heavens
19:48:25 <bcoca> gundalow: what was your intention for this topic in meeting?
19:49:10 <gundalow> Stop > its been a project for 'the next release'  ... since 1.6
19:49:20 <bcoca> ah, glwt ....
19:49:33 <gundalow> As we keep on bouncing around how modules docs should be written
19:49:38 <bcoca> from this discussion .. i think you have your work cut out for you
19:49:41 <gundalow> bcoca: thanks :)
19:49:44 <gundalow> Ok
19:49:49 <bcoca> no really, i do wish you luck and success
19:49:52 <gundalow> </topic>
19:49:59 <gundalow> I know
19:50:00 <bcoca> #topic gitlab service module
19:50:16 <bcoca> @drzraf?  link is 'self reference' so no clue what you want here
19:50:26 <gundalow> shaps: FYI, GitLab
19:51:07 <sivel> https://github.com/ansible/ansible/pull/40053
19:51:33 <bcoca> #topic https://github.com/ansilble/ansible/issues/40053
19:51:43 <sivel> I said I believe that it violates the guidelines, that a module should be explicit and be able to document it's arguments, without the user needing to know about the API
19:51:46 <bcoca> yep, just reformatted comment
19:52:00 <sivel> it has an arbitrary argument
19:52:00 <bcoca> +1 to everything sivel just said
19:52:08 <bcoca> -1 to arbitrary arguments
19:52:15 <sivel> requiring the user to know the API options
19:53:32 <sivel> I had other comments, such as just not using dict comprehensions to make it pass tests, instead of trying to exclude it from py2.6 testing
19:53:56 <sivel> but in the end, it was the arbitrary argument that I think brought it here
19:53:58 <bcoca> i saw, this shoudl not really have made agenda
19:54:15 <sdoran> -1 for all the reasons already stated
19:54:18 <bcoca> also falls under 'thin wrapper' rules
19:54:23 <sdoran> Yup.
19:54:26 <sdoran> Exactly what I was thinking.
19:54:39 <sdoran> If your module links to the API docs, you're probably not adding much value.
19:54:48 <bcoca> #topic https://github.com/ansible/ansible/pull/46687
19:54:54 <bcoca> @Xaroth?
19:54:59 <sivel> just use `uri` at that point
19:55:16 <bcoca> exactly
19:55:18 <sdoran> 👍
19:55:50 <sivel> bcoca: fwiw for #46687, I believe nitzmahone was saying we shouldn't need singular vars, since this also adds plural (list) values
19:56:01 <bcoca> agreed, but they already exist
19:56:10 <sivel> I thought it was adding singular vars
19:56:24 <bcoca> i thought he changed that already ... i need to look again
19:56:31 <nitzmahone> IIRC it added new singular vars (which I'd be -1 for)
19:56:37 <bcoca> but then i dont think any of us disagree on what it should look like
19:56:39 <sivel> `ansible_parent_role_name` is added in this PR
19:56:42 <cyberpear> from minor_changes, it says he's adding 4 vars: singular + list
19:56:45 <sivel> and `ansible_parent_role_path`
19:56:53 <bcoca> i asked early on to make them plural and lists
19:57:01 <bcoca> or at worst, a dict
19:57:05 <sivel> yeah, the submitter just kept the singular too
19:57:07 <bcoca> but lists makre more sense
19:57:13 <nitzmahone> yep
19:57:25 <sivel> so the singular vars should be removed
19:57:29 <bcoca> yep
19:57:38 <nitzmahone> also has "fun" implications for collections
19:57:39 <bcoca> there is existing role_path, thought you meant that
19:57:47 <bcoca> nitzmahone: fun all around ...
19:57:51 <nitzmahone> (eg, should the name be "short name" or "FQ name"?
19:58:02 <sdoran> `ansible_parent_role_names[0]` isn't as nice as a bare variable, but not a big deal
19:58:08 <nitzmahone> or do we need both? (bleh)
19:58:41 <bcoca> if you want short name in all.yml fq: '{{ansible_parent_role_names[0]'}}
19:58:59 <sdoran> I guess we could just add an example of `ansible_parent_role_names | first`.
19:59:00 <bcoca> its trivial for users to create short names .. i dont think we need to do it for em
19:59:06 <sdoran> For the non-programmer crowd.
19:59:08 <bcoca> sdoran: or |last ?
19:59:15 <nitzmahone> bcoca: I'm talking about collections
19:59:17 <bcoca> first would give you 'top role'
19:59:21 <sdoran> According to the docs, the most recent is on top.
19:59:29 <bcoca> ah , thought we did reverse ...
19:59:35 <nitzmahone> the value in that var- should it be "myns.mycoll.myrole" or "myrole"?
19:59:37 <sdoran> Linguistically, I think that's upside down.
19:59:44 <bcoca> agreed
20:00:00 <bcoca> nitzmahone: with collections, always fully qualify
20:00:13 <bcoca> otherwise it can get really  messy when you cross boundries
20:00:17 <sdoran> So remove singular vars, reverse the list order, and add an example of using `| last` to get the "last parent role".
20:00:17 <nitzmahone> I think we had him change that so [0] would always be "my parent" vs [len(...)-1]
20:00:20 <bcoca> i.e coll a includes role from coll b
20:00:29 <sdoran> Ugh.
20:00:36 <sdoran> Yeah, I can see it both ways.
20:00:54 <bcoca> idc about order that much as long as it is clearly documented
20:01:02 <nitzmahone> Basically treat it like role exec stack
20:01:03 <bcoca> both ways make sense in diff contexts
20:01:06 <cyberpear> most recent at [0] makes most sense to me -- it's a stack
20:01:26 <bcoca> most users have no idea what a stack is, barely understand 'lists'
20:01:31 <cyberpear> lol
20:01:34 <bcoca> so it comes down to docs
20:01:47 <bcoca> cyberpear: i would argue many programmers also make no distinction on those
20:01:55 <bcoca> you have to talk LIFO/FIFO
20:02:16 <sivel> WHO IS LIFO?! TELL ME!
20:02:19 <cyberpear> so, we're talking LIFO, but as you said, no one will understand that
20:02:38 <nitzmahone> and if your content is making programmatic decisions based on your caller, you get what you deserve
20:03:00 <bcoca> no .. saddly you don't .. but YOU SHOULD
20:03:39 <bcoca> and on that note ..
20:03:41 <bcoca> #endmeeting