19:01:38 <bcoca> #startmeeting ansible core irc public meeting
19:01:38 <zodbot> Meeting started Tue Mar 26 19:01:38 2019 UTC.
19:01:38 <zodbot> This meeting is logged and archived in a public location.
19:01:38 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:38 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:02:23 <maxamillion> .hello2
19:02:24 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
19:02:30 <nitzmahone> o/
19:03:02 <sdoran> \o
19:03:15 <jillr> o/
19:03:15 <felixfontein> hi!
19:03:29 <bcoca> #topic https://github.com/ansible/ansible/pull/53438
19:03:38 <bcoca> @sajna-shetty?
19:03:44 <Sajna-Shetty> hi
19:04:00 <Sajna-Shetty> This is Sajna Shetty from Dell Emc
19:04:44 <Sajna-Shetty> Could any one please take up new pull request https://github.com/ansible/ansible/pull/53438
19:05:16 <bcoca> anyone here with dell emc experience?
19:05:57 <sdoran> not it
19:06:03 <bcoca> dell emc ome ... not sure what that is
19:06:23 <bcoca> Sajna-Shetty: this storage/management/networkgin?
19:06:25 <cyberpear> what does 'ome' stand for?
19:06:32 <cyberpear> 'dellemc' shouldn't be in the module name
19:06:42 <cyberpear> (product, not vendor, per the dev guide)
19:06:49 <bcoca> ^ he be right
19:06:52 <Sajna-Shetty> Its reviewed by one of the maintainer called Rajeev Arakkal from Dell Emc
19:08:01 <bcoca> dellemc_idrac_firmware is existing module, but breaks the naming rule
19:08:03 <felixfontein> OME = OpenManage Essentials maybe? (https://www.dellemc.com/en-us/solutions/openmanage/essentials.htm)
19:08:05 <bcoca> we should rename that
19:08:56 <Sajna-Shetty> okay
19:09:20 <Sajna-Shetty> dellemc_idrac_firmware is already contributed module
19:09:41 <bcoca> yep, and added with incorrect name, we should not contribute to that by adding more
19:10:13 <Sajna-Shetty> @bcoca will check it
19:10:17 <Sajna-Shetty> thank you
19:10:43 <felixfontein> one question to the group: should this be a _facts or a _info module?
19:10:53 <bcoca> returns ansible_facts
19:11:20 <felixfontein> but talks to a remote machine (from the machine the module runs on), and the variables returned are IP addresses (in the examples), so not easy to use
19:11:50 <cyberpear> (should it return ansible_facts?)
19:12:10 <bcoca> Sajna-Shetty: what info is it actually returning, is it specific to the host? is this generic mangaement info?
19:12:48 <Sajna-Shetty> OME is Open Mange Enterprise.This deals with monitoring and configuring console
19:14:31 <Sajna-Shetty> We are connecting to remote system and retrieving unique information like network address,mac address and hardware details.
19:16:57 <bcoca> ok, so it does make sense as facts
19:17:14 <bcoca> #topic https://github.com/ansible/ansible/pull/53509
19:17:26 <bcoca> another dellemc module, this time irac, but same issues?
19:17:38 <bcoca> @jagadeshnv ?
19:18:09 <cyberpear> https://github.com/ansible/ansible/pull/54421 <- rename dellemc_idrac... to just idrac...
19:18:37 <jagadeeshnv_> hi
19:21:12 <bcoca> so im guessing you also need review, i doubt we have many people with idrac knowledge here either
19:21:29 <bcoca> but if no one else, i'll queue both tickets for review for our requirements
19:22:31 <jagadeeshnv__> Hi, sorry had some issues with internet connectivity
19:22:35 <bcoca> #topic https://github.com/ansible/ansible/pull/53698
19:22:39 <bcoca> @felixfontein?
19:22:43 <felixfontein> I'm here
19:22:54 <felixfontein> I've updated the PR according to the feedback from last session
19:22:56 <felixfontein> (
19:23:12 <felixfontein> I'm currently also adding a unit test, right now I'm trying to get it to run
19:23:25 <bcoca> felixfontein: so we can ignore this till then?
19:23:30 <felixfontein> I mainly want to know whether something else is needed, and wether it has a chance to make it into 2.8
19:23:44 <felixfontein> +h
19:24:01 <bcoca> chance ... but hurry up, you are cutting it very close
19:24:08 <felixfontein> I know
19:24:25 <felixfontein> so is anything else needed besides unit tests? like integration tests?
19:25:11 <bcoca> i have not seen it yet, will try to prioritize review and let you know (or anyone else can if they want to jump in)
19:25:18 <bcoca> #topic https://github.com/ansible/ansible/pull/54272
19:25:22 <bcoca> @cyberpear
19:25:27 * cyberpear waves
19:25:29 <felixfontein> ok, fine. I'll ping you once the unit tests are there
19:25:36 <felixfontein> thanks!
19:26:14 <cyberpear> I believe I've addressed the feedback received for this PR.
19:26:22 <bcoca> didnt i just review that?
19:26:31 <cyberpear> yes
19:26:35 <felixfontein> some people are fast
19:26:49 <bcoca> <nsfw joke censored>
19:27:24 <bcoca> well if someone else wants to review, it was on my list ..
19:27:54 <sdoran> I'll review that one.
19:28:12 <sdoran> How does it handle the old variable names?
19:28:20 <sdoran> sans prefix?
19:28:22 <bcoca> they are still there
19:28:29 <sdoran> Ok.
19:28:35 <felixfontein> does it issue a warning once they contain a value?
19:28:39 <bcoca> cyberpear: you might want to change order as 'old' are higher priority that way
19:28:40 <sdoran> I'll review it.
19:28:45 <bcoca> felixfontein: yes
19:29:05 <cyberpear> bcoca: thanks for the pointer; I'd thought it was the other way around (based on conn plugins, but I could be wrong)
19:29:12 * cyberpear looks again
19:30:00 <bcoca> all plugins follow same rules, same system
19:30:21 <cyberpear> connection plugins seem to use least-important to most-important
19:30:40 <bcoca> yes
19:30:43 <cyberpear> (i.e., ansible_user is specified before ansible_ssh_user before ansible_paramiko_user)
19:31:28 <cyberpear> I've done the same order here (except for the changelog, which has minor_changes before deprecated_features)
19:32:35 <bcoca> #topic https://github.com/ansible/ansible/pull/53960
19:32:44 <bcoca> nosquash?
19:32:47 <cyberpear> selogin module
19:33:11 <bcoca> i would rebase to 2 commits, orig author and yours
19:33:15 <cyberpear> I'd prefer to keep the changes separate... should I open 2 additional PRs and drop the 2 most recent  commits there?
19:33:29 <cyberpear> (i.e., original, cleanup, features)
19:34:24 <cyberpear> I'd be fine squashing the two new features togethr
19:34:29 <cyberpear> I'd like to keep the cleanup separate
19:34:48 <bcoca> #topic https://github.com/ansible/ansible/pull/54319
19:34:54 <bcoca> openstack module defaults group
19:35:18 <cyberpear> seemed straightforward... only question is bikeshedding on the name?
19:35:30 <bcoca> idc
19:35:36 <bcoca> anyone want to review?
19:35:52 <sdoran> I will
19:35:58 <cyberpear> since all openstack modules have the `os_` prfeix, I chose that for the name
19:36:04 <sdoran> I'm fine with that prefix.
19:36:10 <bcoca> #topic https://github.com/ansible/ansible/pull/31452
19:36:28 <cyberpear> already merged, next
19:36:43 <bcoca> #topic warn module
19:37:03 <bcoca> ^ i would say .. no, lets add a 'say' module that has a 'warn' option
19:37:13 * bcoca silently poisons debug module
19:37:18 <felixfontein> about integration testing: should be possible wiht runme.sh approach
19:37:20 <cyberpear> lol
19:37:29 <bcoca> felixfontein: and grep .. lotsa grep
19:37:42 <cyberpear> okay, will keep in mind
19:37:43 <felixfontein> and forcing colors to be inserted, so you can check for the ansi codes
19:38:05 <cyberpear> I was going to overload the existing warn functionality, but haven't started implementation yet
19:38:34 <bcoca> say: msg= type=plain|warn|deprecate|pantsonfire
19:38:59 <bcoca> also want a prompt: module .. so we can stop abusing 'pause'
19:39:00 <cyberpear> sounds good to me
19:39:06 <felixfontein> I'm waiting for    def pantsonfire()    in AnsibleModule
19:39:19 <cyberpear> I've got a whole role dedicated to abusing 'pause' :P
19:39:24 <bcoca> felixfontein: core feature, modules are 'def shortsaretoasty'
19:39:41 <bcoca> cyberpear: you are not alone
19:39:58 <bcoca> #topic https://github.com/ansible/ansible/pull/51776#issuecomment-476650108
19:40:05 <felixfontein> how about an 'anykey' module?
19:40:12 <bcoca> updated config items didnt take into account plugins NOT using config for those items
19:40:14 <felixfontein> (needs shift/ctrl/alt detection though)
19:40:19 <bcoca> felixfontein: that is alias to 'shell'
19:40:25 <cyberpear> how can I identify those plugins?
19:40:35 * cyberpear wants to get it fixed to keep the change
19:40:50 <bcoca> https://github.com/ansible/ansible/pull/53037 <= this is my START of the fix, just for paramiko
19:41:11 <bcoca> we really should revert that PR and do the modules one by one
19:41:12 * cyberpear subscribes
19:41:14 <bcoca> er plugins
19:41:53 <cyberpear> I'll take a look later today.  Thanks for the pointer to the bug.
19:42:17 <cyberpear> That one must have always been broken, not broken by my commit.
19:42:17 <bcoca> #topic https://github.com/ansible/ansible/pull/54315
19:42:29 <bcoca> tls params stanarization .. didnt we already vote on this?
19:42:53 <cyberpear> yes.  Just hoping to have it for 2.8...
19:43:05 <cyberpear> I believe I've hit all the cases that were as simple as renaming params
19:43:13 <cyberpear> I'll leave the more complex cases for 2.9
19:43:28 <felixfontein> I guess it needs to be merged before Thursday for that (because of some support:core things)?
19:43:31 <cyberpear> (like some modules expect a string "enable" "disable"
19:43:39 <bcoca> cyberpear: if you dont remove WIP .. mostly it will be ignored
19:43:53 * cyberpear will remove WIP shortly
19:44:02 <cyberpear> I've just finished shortly before the meeting
19:44:15 * cyberpear went through 11k lines of grep output
19:46:10 <felixfontein> I think it would be great to have it in 2.8
19:46:30 <felixfontein> (and if it won't be merged this week, then at least the community support part of it)
19:46:49 <cyberpear> My most recent push updated all the plugins... in-progress CI shows I need to update a couple of the tests to make it happy
19:46:57 <cyberpear> updates after updating all modules passed CI
19:47:04 <felixfontein> I guess we need some changelog fragments for this (or even a porting guide entry?)
19:47:20 <cyberpear> yeah, I'll add changelog + porting guide, like for the username->user rename
19:47:26 <bcoca> porting guide? thought you made aliases?
19:47:33 <cyberpear> I did make aliases
19:47:44 <felixfontein> bcoca: maybe mention "stop using the old names" in there ;)
19:47:46 <cyberpear> is porting guide only for breaking changes?
19:48:08 <sdoran> This should be transparent and therefore doesn't require a porting guide entry.
19:48:09 <cyberpear> I put a porting guide entry for the pass->password rename, but old vars still work
19:48:10 <bcoca> k, as long as they appear as principal in docs i would not force porting, some of the 'old names' are 'context specific' and those using the api are more familiar with .. and we should not remove
19:48:20 <cyberpear> ack, no porting guide
19:48:28 <bcoca> cyberpear: dont think you needed that either
19:48:29 <felixfontein> +1
19:49:38 * cyberpear dropped 'WIP'
19:50:38 <bcoca> #topic open floor
19:50:57 <cyberpear> https://github.com/ansible/ansible/pull/52608
19:51:19 <cyberpear> I should set up some openstack WG meetings and see if anyone shows up...
19:51:26 <cyberpear> but if someone can take a look, I'd appreciate it.
19:51:45 <bcoca> i would punt to OS crowd since i really canot say if that is good change or not
19:52:01 <bcoca> you can normally ping them in #ansible-devel also
19:52:11 <cyberpear> ok, will try that
19:52:13 <sdoran> Changelog fragments need double backticks for inline code since they get assembled into an RST doc, not Markdown.
19:52:38 <cyberpear> ok, I'll take a note and update existing changelogs
19:53:22 <sdoran> You should be able to get some OpenStack folks to give that quick look and say whether it's ok.
19:53:46 * cyberpear fixed the back-tick issue
19:54:00 * cyberpear will ping OS folks
19:54:57 <bcoca> #endmeeting