15:00:15 <thaumos> #startmeeting ansible dev meeting
15:00:15 <zodbot> Meeting started Thu Sep 28 15:00:15 2017 UTC.  The chair is thaumos. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:15 <zodbot> The meeting name has been set to 'ansible_dev_meeting'
15:00:23 <thaumos> #chair jtyr
15:00:23 <zodbot> Current chairs: jtyr thaumos
15:00:36 * ryansb waves
15:00:40 <thaumos> #chair ryansb
15:00:40 <zodbot> Current chairs: jtyr ryansb thaumos
15:00:45 * shertel waves
15:00:51 <thaumos> #chair shertel
15:00:51 <zodbot> Current chairs: jtyr ryansb shertel thaumos
15:00:51 <Qalthos> \o
15:00:55 <thaumos> #chair Qalthos
15:00:55 <zodbot> Current chairs: Qalthos jtyr ryansb shertel thaumos
15:01:27 <albertom> o/
15:01:47 <thaumos> #chair albertom
15:01:47 <zodbot> Current chairs: Qalthos albertom jtyr ryansb shertel thaumos
15:01:51 * mikedlr wonders 'wot is a dev meeting - does it have an agenda ticket'  then waves anyway.
15:02:05 * bcoca was using ansible_core_meeting
15:02:16 <thaumos> #chair mikedlr
15:02:16 <zodbot> Current chairs: Qalthos albertom jtyr mikedlr ryansb shertel thaumos
15:02:29 <thaumos> can the name be changed after the fact?
15:02:37 <bcoca> end + start?
15:02:43 <thaumos> yeah, eff that
15:02:48 <thaumos> I'll call it core next time
15:02:52 <mikedlr> maybe it's a better name?
15:03:08 <thaumos> I just got feedback to not call it community meeting or something close to that, maybe to call it the dev meeting
15:03:16 <thaumos> since this is all about merging stuff into devel and what not.
15:03:26 <thaumos> there's just too many meetings now, I can't keep track.
15:03:49 <sdoran> We should hold a meeting to discuss what to call the meetings.
15:03:53 <thaumos> #topic set missing default values for ec2 inventory
15:03:55 <thaumos> #link https://github.com/ansible/ansible/pull/28375
15:03:59 <bcoca> meta meeting
15:04:30 <thaumos> @jtyr this is your first one.  @shertel and @ryansb either of you have more to review for this?  I see that @sdoran has chimed in on it as well.
15:04:36 <jtyr> yes, that one just needs review
15:04:45 <shertel> +1 to merge that
15:04:51 <sdoran> Just waiting on ryansb to +1 it
15:04:55 <sdoran> +1 to merge from me
15:04:56 * ryansb will do
15:05:02 <thaumos> cool,
15:05:10 <thaumos> #action PR to be merged by ryansb or shertel
15:05:30 <thaumos> jtyr: do you still need your second topic looked at?  I am confused by your last comment
15:05:49 <jtyr> yes
15:06:03 <jtyr> we discussed it briefly yesterday
15:06:27 <thaumos> is this carry over from #ansible-devel you mean
15:06:36 <jtyr> jimi|ansible agreed that there is currently no solution that could replace 'params`
15:07:12 <bcoca> mostly we dont want anything that does it the way that params does it
15:07:36 <bcoca> we do have existing ways to provide some of the functionality, just not in a  way that bypasses our validation and security
15:07:57 <jtyr> it's all about removing 'params' from multiple modules although this option was there since the beginning of the existence of the modules ...
15:08:10 <thaumos> #topic follow up discussion to params
15:08:35 <bcoca> jtyr: i would argue that it a consequence of being missed in review
15:08:41 <jtyr> bcoca: I would prefer to get rid of 'params' and have better implementation in args ...
15:09:17 <jtyr> ansible could then validate if args contain some option which shouldn't be logged (using nolog in AnsibleModule definition)
15:10:11 <thaumos> as bcoca said yesterday, args are still here; it's still being discussed about what's going to happen with "improving" args.
15:10:21 <jtyr> bcoca: missed in a review in multiple modules even if that behavior was documented in EXAMPLES? ... unlikely ...
15:10:52 <jtyr> args are marked as "deprecated" ...
15:10:58 <thaumos> @jtyr, there are A LOT of modules... Things will get missed.  Plus now, we have automerge of community modules so things will go through the pipe as well.
15:11:19 <bcoca> does not mean we shouldn't correct things we find that are wrong
15:11:27 <thaumos> I also like to mention, at one point there were only two people that truly curated the project.
15:12:14 <jtyr> bcoca: 'wrong' is not the right word
15:12:39 <bcoca> we disagree on that
15:13:20 <jtyr> params allow to do a bit more than args ... both are not doing any validation whether the options should be obfuscated in logs ...
15:13:41 <jtyr> if we add the obfuscation, why we couldn't keep args supported?
15:13:59 <jtyr> and perhaps extend it to allow task options overrides?
15:14:04 <bcoca> args does NOT bypass validation, does not need to do it itself, params bypasses it
15:14:17 <jtyr> that's the actually only difference between params and args
15:14:17 <bcoca> args is 'general' and implemented for all tasks, params is specific to the plugin
15:14:33 <bcoca> not really, but those are the ones that matter the most to me
15:14:46 <bcoca> and enough to justify removal, imo
15:15:45 <jtyr> the thing is that you removing functionality with no alternative solution ... that's not good as it breaks a lot of roles using that feature ...
15:16:17 <bcoca> the whole concept of 'overriding optoins' is something i cannot get behind, providing defaults .. yes, but not overrides, its too much magic in the wrong direction
15:16:41 <bcoca> jtyr: I normally try to avoid that, but i think this is a case in which we must
15:17:23 <jtyr> OK, if I would ignore the override thing ... how do we add options to task after args is removed in 2.6?
15:17:46 <jtyr> default options for module won't cut it ...
15:18:07 <jtyr> or are you gonna lift the args deprecation?
15:18:31 <bcoca> pointed you yesterday at 2 of the options we are looking at
15:18:43 <bcoca> and i would be willing to discuss the deprecation
15:19:11 <thaumos> IF args are to be removed in 2.6, which by the way isn't planned yet, we will definitely think of how to improve it.
15:19:27 <jtyr> 'module defaults' and 'auth plugins' won't cut it ...
15:19:52 <bcoca> jtyr: only if you want 'overrides' .. which i think the whole team has been clear on, we dont
15:20:09 <jtyr> forget about overrides now ...
15:20:11 <bcoca> module defaults should be able to provide everything args does today
15:20:15 <jtyr> imagine file module ...
15:20:16 <abadger1999> thaumos: I think it is.
15:20:23 <jtyr> you don't want to set defaults for that module
15:20:24 <abadger1999> thaumos: We deprecated those in 2.0.
15:21:18 <bcoca> and you still have yaml anchors, which while 'not pretty' i believe are a good choice as the problem you have with them 'file locality' i find as a feature, keep the 'magic' a bit more obvious and the user can audit easily
15:21:32 <thaumos> #chair abadger1999
15:21:32 <zodbot> Current chairs: Qalthos abadger1999 albertom jtyr mikedlr ryansb shertel thaumos
15:21:44 <jtyr> bcoca: we discussed anchors with jimi|ansible and he agreed that that's not a solution ...
15:22:02 <jimi|ansible> i did not agree that, they're useful but maybe not exactly what you want
15:22:21 <bcoca> i was going to say, that was not exactly what he said
15:22:43 <jtyr> jimi|ansible: you said that I would have to generate task files dynamically to get the same functionality args are providing ...
15:23:05 <bcoca> that is not wrong, but not the same thing as 'not a solution'
15:23:10 <bcoca> just not the same functionality
15:23:18 <thaumos> #chair jimi|ansible
15:23:18 <zodbot> Current chairs: Qalthos abadger1999 albertom jimi|ansible jtyr mikedlr ryansb shertel thaumos
15:23:22 <jimi|ansible> you may be mixing up convos from yesterday, because i'm pretty sure i didn't say that
15:23:37 <jtyr> yeah, then the solution could also be not to use Ansible at all ... that's not the right approach ...
15:23:38 <bcoca> also, there is a way around that by making the yaml anchor 'dynamic' based on vars passed in
15:23:50 <abadger1999> jtyr: Aren't we ignoring overrides now?
15:23:57 <jtyr> yes
15:24:18 <abadger1999> So don't anchors work if you ignore overrides?
15:24:25 <bcoca> also, aren't we drifting away from the topic? which is removing params from the plugin?
15:24:28 <abadger1999> jtyr: (it was agaffney who said dynamically generating the playbook)
15:24:45 <bcoca> ^ and again, there is easy way around that
15:24:50 <jtyr> how do you pass defaults or vars variable to an anchor?
15:25:14 <bcoca> in the anchor you make it depend on the vars/defaults
15:25:24 <bcoca> the anchor itself is just yaml
15:25:25 <jtyr> abadger1999: oh, yeah ... different nick ... sorry jimi|ansible ;o)
15:26:13 <jtyr> bcoca: so the anchor must have static list of options ... that doesn't help much ...
15:26:37 <bcoca> why?
15:26:44 <bcoca> also, not true
15:26:49 <abadger1999> thaumos: Just checked... yes, Using variables for the args dict is going away in 2.6.
15:26:57 <jtyr> if I cannot make the whole anchor's content as a variable then it makes no sense ...
15:27:05 <bcoca> jtyr: again, not true
15:27:20 <abadger1999> (individual args is okay.  it's setting args: "{{ dict }}"   that's going away)
15:27:23 <bcoca> and yes, you can
15:27:38 <bcoca> abadger1999: but that is exactly what he wants
15:27:52 <abadger1999> bcoca: <nod>  I'm clarifying for thaumos
15:28:00 <bcoca> roger
15:28:07 <thaumos> abadger1999: thx for looking at that.  My point is, we're only discussing what's going to be in 2.5.  We're ahead of ourselves.
15:28:10 <jtyr> bcoca: please could you show me how I can define an anchor whose content is another variable? ... no keys defined inside that anchor ...
15:28:13 <abadger1999> k
15:28:28 <bcoca> helo: &helo "{{var}}" ?
15:29:01 * jtyr is checking
15:30:08 <jtyr> bcoca: it doesn't work
15:30:19 <jtyr> anchor must be a dict not string
15:31:34 <bcoca> not true, it can be any yaml var type
15:31:58 <bcoca> https://gist.github.com/bcoca/a9d373c2520dbf03bfbb07aa5aaa2719
15:32:18 <sivel> I am still strongly infavor of saying that using default(omit) is the best practice/recommendation
15:32:26 <bcoca> ok: [localhost] => {
15:32:27 <bcoca> "test1": "helo"
15:32:28 <bcoca> }
15:32:30 <bcoca> sivel: agreed
15:32:56 <bcoca> jtyr:  none of your statements about anchors are accurate
15:33:14 <bcoca> even if they were, i would still not consider keeping 'params'
15:33:15 <jtyr> sivel: not if the module has 30+ options ...
15:33:31 <sivel> of course it is
15:34:22 <jtyr> sivel: I don't agree ... it's a nightmare to parametrize all 30+ possible options only because there is no other way how to do it ...
15:34:40 <sivel> it's a 1 time thing, and more accurately reflects what is going to happen, as opposed to arbitrary vars passing that isn't explicit
15:35:00 <bcoca> and breaks auditabilty, one of the things i most like about ansible
15:35:11 <sivel> manging something like "params" makes things much more confusing and difficult to troubleshoot
15:35:23 <thaumos> Alright, I am going to have to put a hold on this conversation in a little bit.  We aren't getting anywhere.
15:35:30 <sivel> ++
15:35:36 <abadger1999> thaumos: need a vote I think
15:35:44 <bcoca> +1 to remove
15:35:50 <thaumos> what are we voting on, it's going to get removed.
15:36:05 <jtyr> bcoca: https://pastebin.com/GLg35MKz ... this is syntax error ...
15:36:08 <abadger1999> +1 remove
15:36:46 <abadger1999> there may be a use case here but params as a solution is worse than the problem.
15:37:11 <sdoran> +1 to remove
15:37:39 <jtyr> abadger1999: I'm not against removing params ... I just would like agrs stay as a replacement ... although it doesn't do replacements ...
15:38:26 <thaumos> jtyr, args are being revisited.
15:38:33 <thaumos> params are being removed.
15:38:45 <thaumos> args will be discussed in the future before deprecated.
15:38:46 <jtyr> thaumos: they they should be not marked as deprecated ...
15:38:55 <thaumos> they were marked in the past.
15:39:11 <jtyr> thaumos: then let's undo it ;o)
15:39:29 <abadger1999> jtyr: setting htem via a dict is marked as deprecated because it is unsafe.  security trumps convenience.
15:39:37 <thaumos> I'd rather improve than step backwards.
15:39:44 <thaumos> we step back way too much as it is.
15:40:17 <abadger1999> we can look at whether there's a way around the security concerns that lets us kep that functionality, but can't reprioritize convenience over security.
15:40:34 <sivel> +1 to remove, sorry.  Looked away
15:40:45 <jtyr> abadger1999: it's unsafe the same way like params ... this is why I wanted to implement some security checking (check for nolog=True in AnsibleModule) ...
15:41:55 <sivel> In any case jimi said params was being removed regardless, due to a CVE
15:42:04 <sivel> not sure a vote was really needed in that context
15:42:16 <thaumos> only because abadger1999 called for one :-)
15:42:35 <thaumos> he keeps me from turning into The Hyde BDFL
15:42:45 <sivel> I like BDFL :)
15:42:49 <abadger1999> sivel: the CVE is related but different.
15:43:54 <jtyr> abadger1999: if args will stay then I'm happy to remove params ...
15:44:09 <thaumos> okay, moving on from this topic. we will revisit the args discussion at a later day.
15:44:22 <thaumos> we have one more topic to cover that albertom has been patiently waiting to discuss
15:44:39 <thaumos> #action discussion to continue over args at a later day for 2.6.
15:44:41 <albertom> sup!
15:44:46 * jtyr is sad
15:44:58 <thaumos> #topic os keystone endpoint module submission
15:45:04 * albertom passes a puppy to jtyr
15:45:06 <albertom> dont be
15:45:17 <thaumos> #link https://github.com/ansible/ansible/pull/29031
15:45:55 * jtyr bited the puppy's head off
15:46:06 <thaumos> ...
15:46:08 <sivel> I think we need input from one of the openstack module maintainers.  I'd review, but it would only be code review
15:46:43 <sivel> although looks like there are 2 shipits from people who were pinged
15:47:01 <sivel> but only 1 since recent updates
15:47:20 <thaumos> albertom: like dag said, we just need one more shipit from the Openstack community to have this considered to be merged.
15:47:28 <thaumos> same person said shipit twice, @sivel
15:47:32 <shertel> does the bot pick up shipits in review comments?
15:48:20 <sivel> thaumos: ah, thought I saw one from mgale, but was wrong
15:48:32 <thaumos> I had to doubletake on it as well, sivel
15:48:45 <sivel> shertel: unknown,
15:48:52 <thaumos> I don't believe it does shertel
15:49:24 <sivel> jtanner doesn;t seem to be in here, and I beliefe thaumos is correct
15:49:26 <thaumos> that being said, it's a new module so it still needs us to merge it.
15:49:28 <rcarrillocruz> i can look at the keystone module
15:49:30 <rcarrillocruz> probably tomorrow
15:49:34 <rcarrillocruz> albertom: ^
15:49:37 <albertom> good!
15:49:54 <thaumos> @sdoran you interested in looking at this too?
15:50:05 <sdoran> Yup
15:50:39 <jtanner> Iirc bot does see shipits in review coomoents as of a few weeks ago
15:51:17 <thaumos> oh right on
15:51:33 <shertel> nice!
15:51:59 <thaumos> either way, rcarrillocruz is on the team_openstack list.  If he gives it a shipit we're good to have it merged.
15:52:18 <thaumos> since it's new it'll still be a manual ack
15:52:21 <rcarrillocruz> yah, promise to look early in my morning and merge it if all good
15:52:26 <rcarrillocruz> otherwise albertom ping me directly
15:53:11 <albertom> ack
15:53:11 <thaumos> #action rcarrillocruz and sdoran to look at the PR
15:53:28 <thaumos> #action albertom to poke at rcarrillocruz if needed
15:53:34 <thaumos> #topic Open Floor
15:53:49 <thaumos> any last items not covered to be discussed?
15:54:14 <mikedlr> review my RDS modules pls.  It's a strategic feature for 2.5 since we want to deprecate the old rds module..
15:54:42 <thaumos> #info play with the new shiny RDS module and provide feedback folks!
15:54:57 <thaumos> @mikedlr, link to the PR?
15:55:01 <abadger1999> #link https://github.com/ansible/ansible/pull/30746
15:55:16 <thaumos> thx abadger1999
15:55:18 <mikedlr> thanks abadger1999
15:55:52 <mikedlr> N.B. that's got multiple modules in it so that I can run proper integration tests and thus includes some merge commits;  the final PRs will be separated and clean.
15:58:27 <thaumos> 👍
15:58:36 <thaumos> alrighty, if nothing else I am going to end the meeting
15:58:41 <thaumos> thanks everyone!
15:58:47 <thaumos> #endmeeting