19:00:51 <bcoca> #startmeeting ansible core public irc meeting
19:00:51 <zodbot> Meeting started Tue Apr 23 19:00:51 2019 UTC.
19:00:51 <zodbot> This meeting is logged and archived in a public location.
19:00:51 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:51 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:01:31 * cyberpear waves
19:01:48 <sdoran> o/
19:02:46 <bcoca> #topic open floor
19:05:25 <cyberpear> wrt the role spec proposal, would that allow something like auto-converting boolean values from "true"/"false" to bools?
19:05:47 <bcoca> not allow, but enforce
19:06:00 <bcoca> you are already 'allowed'
19:06:15 <cyberpear> I meant would it happen automatically?
19:06:33 <bcoca> not sure what you mean
19:06:38 <cyberpear> i.e., I send string "7.6" for a value that's a float, and it gets consumed as a float rather than erroring out, or as a string
19:06:50 <bcoca> depends
19:07:19 <bcoca> how you consume is much more important than how it is defined and/or validated, spec does not change that
19:07:39 <bcoca> jsut ensures it is a valid bool/int/float, what happens to it afterwards ... that is not something we can enforce
19:08:11 <bcoca> x: "{{ ' ' + var_validated_as_int }}" <= will make x a string
19:08:17 <cyberpear> okay, so role spec would error out on string "7.6" if it is expecting a float? -- I could see an argument for either way
19:09:02 <bcoca> depends on how you want to enforce, it can check the value does not error when float(value), i.e "7.6" and 7.6 work, but 'A7.6' does not
19:09:36 <cyberpear> I guess that's yet to be sorted in the proposal...
19:09:54 <bcoca> even if it was 7.6 at definition, does not mean it will be at consumption, so even if we make it strict ( isisntance(x, int) ), does not guarantee it will stay int
19:10:08 <bcoca> cyberpear: already 2 implementations, one in use
19:10:09 <cyberpear> given the current default behavior of `myvar: "{{ 1 + my_int }}"` returning a string, I'd want the role spec to auto-convert that back to an int
19:10:33 * cyberpear aware of jinja2-native option
19:10:33 <bcoca> role spec validates existing vars, has nothing to do with conserving type
19:10:51 <bcoca> use 'native types' setting if you want to conserve type
19:10:53 <bcoca> diff feature
19:10:58 <sivel> the goal is that the role spec would use the same code as used by modules to define and validate a spec
19:11:14 <sdoran> The validation functions try to convert the given value to the type and raise `TypeError` if it can't be converted.
19:11:17 <cyberpear> my understanding is that modules currently do this coversion automatically
19:11:51 <cyberpear> perfect, then role spec seems like it will solve some other issues that just its face value...
19:12:18 <cyberpear> What are the next steps for role spec?  Is it on the road map for a particular release? Does it need particular help?
19:12:35 <bcoca> its been finished and stalled/rejected
19:13:19 <bcoca> meanwhile network-tools roles have their own version of it
19:13:26 <cyberpear> what's the biggest issue?
19:13:49 <sivel> the current version, was attempting to directly use `AnsibleModule`, but a subclassed version.
19:13:52 <sivel> That was one problem
19:14:02 <sivel> also the way that the spec validation task was inserted
19:14:02 <bcoca> https://github.com/ansible/ansible/pull/44983
19:14:31 <bcoca> sivel: actually that was v4 of implemetnation iirc, initial used its own but comment was made 'it should reuse argspec'
19:15:03 <sdoran> The validation methods used by modules were moved in 2.8 to make them generally available to other things besides modules.
19:15:14 <bcoca> and i dont even find the ansbilemodule hack as a stopper (we have other things already doing that .. *cough GCE cough*)
19:15:27 <cyberpear> (indeed, no updates on the PR since last discussion)
19:15:37 <sivel> it ws tabled for the duration of 2.8 dev
19:15:53 <sivel> deemed not a priority
19:15:58 <cyberpear> bring on 2.9! :P
19:16:11 <bcoca> there were also issues with not implementing it as a plugin, not letting it auto run, not wanting it to be reused in other parts (*plays?)
19:16:46 <bcoca> and that this should be exclusive of ansible-role cli (which is really redundant sice `ansible -m include_role `)
19:17:30 <cyberpear> so the 'tl;dr' sounds like: Everyone agrees it's a good idea, there's just no acceptable implementation yet.
19:17:44 <cyberpear> one big improvement that could be made to 'ansible -m include_role' wolud be to put the task names
19:17:45 <bcoca> not really, some of us think its good idea, many are oposed
19:17:55 <bcoca> cyberpear: task names?
19:18:27 <cyberpear> I tried it when 2.7 came out, and each task in the role is output as if it were run ad-hoc, without any idea of where in the role the task is coming from
19:18:41 * cyberpear hasn't tried in months, though
19:19:22 <bcoca> that is a callback issue, minimal callback does not expect more that THE ONE task, by forcing it to do multiple tasks .. you invalidte the design of the callback
19:19:23 <cyberpear> I still end up making a trivial playbook to run each role during its development because the output given by 'ansible-playbook' is more informative than 'ansible -m include_role'
19:19:24 <agaffney> cyberpear: that's due to the default callback plugin used by 'ansible'
19:19:28 <bcoca> ^ just switch callback
19:19:55 * cyberpear makes note to look at the callback
19:20:19 <bcoca> i should really fix the way of setting callbacks for adhoc, right now its a pain
19:20:25 <agaffney> there's a separate config option that tells the 'ansible' binary use the configured callback plugin (rather than using 'minimal' or 'oneshot')
19:20:26 <bcoca> adhoc_callback=X
19:20:49 <agaffney> bcoca: that would be nicer, for multiple reasons
19:21:06 <cyberpear> for most ad-hoc tasks, the default is fine, but good to know I can get the desired functionality w/ a config change
19:21:16 <bcoca> global_callbacks= playbook_callbacks= adhoc_callbacks + global_stdout_callback ...
19:21:33 <bcoca> cyberpear: i recommend unixy for this case
19:25:37 * cyberpear celebrates argparse
19:26:10 <bcoca> ^ i was planning to do 'hierarchacal callback config' if i ever got 'yaml config files' up and running
19:26:24 <bcoca> ^ izpells
19:33:17 <agaffney> bcoca: what do you mean by hierarchical callback config?
19:35:09 <maxamillion> .hello2
19:35:11 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
19:35:26 <maxamillion> sorry, had a meeting conflict for the first half hour
19:35:31 * maxamillion reads scrollback
19:38:36 <bcoca> https://gist.github.com/bcoca/3bf24ef91f93066abc13b489aa84e783 <= agaffney
19:39:36 <agaffney> ah, nice
19:39:56 <cyberpear> would be convenient
19:42:01 <bcoca> was part of config proposal from start , just phase 5 .. more like 15 at this point
19:42:09 <bcoca> aslo 'mergable configs'
19:42:20 <bcoca> i.e /etc/ansbile.yml + ~/ansible.yml
19:42:49 <bcoca> with each file having setting 'merge=all|none|up|down'
19:42:50 <cyberpear> folks would like that, but in its absence, I've been advocating env vars in .bashrc, etc
19:43:11 <cyberpear> s/advocating/advertising/
19:43:19 <bcoca> cyberpear: its a worka round, it would be nice per 'site/user/project'
19:43:26 <cyberpear> agreed
19:53:47 <bcoca> k, if nothing else ..
19:53:49 <bcoca> #endmeeting