16:00:24 <Qalthos> #startmeeting Ansible Network Working Group
16:00:24 <zodbot> Meeting started Wed Apr  3 16:00:24 2019 UTC.
16:00:24 <zodbot> This meeting is logged and archived in a public location.
16:00:24 <zodbot> The chair is Qalthos. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:24 <zodbot> The meeting name has been set to 'ansible_network_working_group'
16:00:44 * ikhan waves
16:00:51 <Qalthos> #chair ganeshrn ikhan privateip trishnag pabelanger
16:00:51 <zodbot> Current chairs: Qalthos ganeshrn ikhan pabelanger privateip trishnag
16:01:01 <Qalthos> #topic Core Updates
16:01:44 <Qalthos> #info Freeze has slipped another week
16:02:05 <Qalthos> #info Community freeze is now next week (2019-04-11)
16:02:47 <Qalthos> #link https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_8.html gets updated whenever this happens
16:02:57 <Qalthos> For those of you who want to follow along at home
16:03:27 <Qalthos> I know we've done this a lot lately, but it is very unlikely to happen again
16:03:52 <Qalthos> If you want something in for 2.8, it should be in a PR, and ideally already be merged
16:05:31 <Qalthos> Nothing else from the core team this week
16:06:04 <Qalthos> #link https://github.com/ansible/community/labels/network is where you can find the agenda for this meeting
16:06:21 <Qalthos> So let's get in to it
16:07:01 <Qalthos> Skipping Anil, he's not here and I think his PRs have been addressed
16:07:25 <Qalthos> #topic New module asa_og
16:07:58 <Qalthos> Federico87_: I see your PR is failing tests?
16:08:09 <Federico87_> Hello! Yes, let me explain what is going on
16:08:33 <Qalthos> #chair justjais Federico87_
16:08:33 <zodbot> Current chairs: Federico87_ Qalthos ganeshrn ikhan justjais pabelanger privateip trishnag
16:09:15 <Federico87_> I have been asked to remove all provider stuff from that module but in order to do that some fix are required in module_utils/asa.py
16:09:18 <Federico87_> PR #54783
16:09:48 <Qalthos> Does that PR also need to do something about `provider` and `authorize`?
16:09:57 <Federico87_> after aplied the changes required, pipeline failed fro E323
16:10:26 <Federico87_> Not sure, is just a quick fix for key:value error
16:11:14 <Federico87_> going back to the error E323, I don't see the  DOCUMENTATION.options in my module so I am not quite sure how to fix that
16:11:30 <Qalthos> Ah, no, I see now
16:12:07 <Qalthos> The issue is `extends_documentation_fragment: asa`, which lists parameters your module doesn't support
16:12:29 <Federico87_> just need to get rid of that line?
16:14:41 <Qalthos> https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/doc_fragments/asa.py
16:15:12 <Qalthos> ...looks like it. It seems to only be concerned with those options anyway
16:15:50 <Federico87_> When I had argument_spec.update(asa_argument_spec) in my module was fine though (if that can help in some way)
16:16:34 <Qalthos> Right, because you had documented options that you were using
16:17:05 <Qalthos> You need to both remove them from the argspec and the DOCUMENTATION string for sanity tests to pass
16:17:18 <Federico87_> not having provider anymore I don't see point is ude them :) looking briefly at the link, seems mainly provider stuff related
16:17:43 <Qalthos> In this case, it was confusing as those options weren't actually specified in the module itself
16:17:43 <Federico87_> I have been asked to remove all argspec
16:18:07 <Federico87_> sorry, I mean argument_spec.update(asa_argument_spec)
16:18:17 <Qalthos> I mean, your module still needs /some/ argspec, otherwise it has no options
16:18:20 <Qalthos> Right
16:18:27 <Federico87_> in argument_specific dict I do not have anything related to it
16:18:41 <Federico87_> argument_spec = dict(         name=dict(required=True),         group_type=dict(choices=['network-object', 'service-object', 'port-object'], required=True),         protocol=dict(choices=['udp', 'tcp', 'tcp-udp']),         host_ip=dict(type='list'),         description=dict(),         group_object=dict(type='list'),         ip_mask=dict(type='list'),         port_range=dict(type='list'),         port_eq=dict(type='
16:19:22 <Qalthos> Right, but it's still getting pulled in to your DOCUMENTATION
16:19:34 <Qalthos> I made a note on your PR which should solve the problem
16:19:54 <Qalthos> Remove the line and sanity tests should pass that test
16:20:08 <Federico87_> Yeap
16:20:28 <Federico87_> Thanks for that. If we merge in the next days any chance to see it in 28?
16:20:38 <Federico87_> *2.8
16:21:09 <Qalthos> There's no chance about it, if it gets merged before branch, it'll be in
16:21:28 <Qalthos> And my guess is it'll probably be merged
16:21:55 <Federico87_> Ok, thanks a lot for the info
16:22:11 <Qalthos> Federico87_: Anything else before we move on?
16:22:22 <Federico87_> I am ok, thanks
16:22:44 <Qalthos> #topic nxos_file_copy parameters
16:23:47 <mikewiebe> Qalthos: Trying to figure out the best way to handle the deprecated 2.9 parameters for this module (host, username and password)
16:24:06 <Qalthos> mikewiebe: This is because the module doesn't use the connection directly?
16:24:08 <mikewiebe> We get these from the ansible environment
16:24:29 * Qalthos doesn't entirely remember how this module works
16:25:39 <mikewiebe> The default workflow for the module is to copy files from the ansible controller to the device.  It needs to username/password for the device to copy the file.
16:26:12 <mikewiebe> It gets this information from group_vars or the ansible ENV automatically and sets this in the action plugin
16:26:13 <Qalthos> My first reaction is to move things into an action plugin a la net_put/net_get
16:27:27 <mikewiebe> That is already being done here: https://github.com/ansible/ansible/blob/e433feaecc3792a74854eedb88e117f0cfa4be49/lib/ansible/plugins/action/nxos.py#L49
16:27:58 <mikewiebe> The problem is that the _task_args are host, password and username which are being deprecated
16:28:17 <mikewiebe> What I show here is the change to use nxos_host, nxos_password, nxos_username instead
16:28:39 <mikewiebe> But, I don't want to expose these as user parameters in the module task.
16:34:45 <Qalthos> You're setting task args in the action plugin yes, but that's all you're doing
16:34:53 <Qalthos> Consider the net_put module https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/network/files/net_put.py
16:35:35 <Qalthos> The only contents of that file are documentation strings, because everything it does is in the action plugin
16:37:34 <Qalthos> This isn't really a recommended path for a lot of modules, but as you're not really using the connection plugin anyway, you might as well do that sort of thing in its own custom action plugin
16:37:39 <Qalthos> (like https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/net_put.py)
16:39:24 <Qalthos> net_put has the benefit of only running on network_cli, and can therefore get away with connection.copy_file(), but you should be able to do the same sort of thing you're doing now in your module, I think
16:43:06 <Qalthos> That said, this is not going to make 2.8, so we don't have to do something literally today, and I know trishnag is aware of the issue
16:46:20 <Qalthos> mikewiebe: Does that make sense? I don't know if maybe you discarded this as an option before or if I'm overlooking something
16:48:31 <mikewiebe> Sorry!  Got pulled away for a few minutes
16:49:46 <mikewiebe> Thanks for the pointers.  I will look at those more closely and see if I can leverage that for this case and will add more questions in the PR if needed
16:49:59 <Qalthos> mikewiebe: Sounds good
16:50:13 <Qalthos> Moving on
16:50:28 <Qalthos> #topic New module exos_vlan
16:51:51 <Qalthos> ujwalkomarla: My understanding is there are some deficiencies in exos' restconf that means you might have to fall back to jsonrpc for some calls
16:52:24 <Qalthos> Is that true for exos_vlan? I don't see any calls to `run_commands` here
16:52:49 <ujwalkomarla> No, exos_vlan is completely based on exos restconf.
16:53:41 <ujwalkomarla> In future, other modules can probably need to use both restconf and jsonrpc...
16:54:52 <Qalthos> ujwalkomarla: would that be up to the user or the module author?
16:55:02 <ujwalkomarla> Module author..
16:55:54 <Qalthos> And that's because some functions are not yet supported by the OS over RESTCONF?
16:56:04 <ujwalkomarla> Correct
16:57:46 <ujwalkomarla> As I see, an ansible user working with EXOS, will be using 'httpapi' as the connection type.. The modules themselves will be written to use restconf and jsonrpc..
16:58:37 <Qalthos> Alright. I don't see a particular reason to not ask that exos_vlan use the common restconf code.
17:00:01 <Qalthos> I'll try to get you some guidance on how we want to approach future modules
17:00:51 <ujwalkomarla> Yes, that sounds good. But most of the restconf code is in the modules 'restconf_get' and 'restconf_config'.
17:01:16 <ujwalkomarla> And the 'httpapi' plugin for 'restconf' has the error handling..
17:01:22 <Qalthos> #action Qalthos figure out how mixed-protocol modules might work
17:03:22 <Qalthos> Right, so use the restconf httpapi plugin (and the module_utils code if it helps the module) by setting network_os to restconf
17:03:51 <Qalthos> There should be some changes coming in 2.9 to make that less... awful
17:05:15 <ujwalkomarla> Looking forward to that.
17:05:29 <Qalthos> (mostly not requiring it to be set from network_os, which is confusing at best for things like restconf, and outright problematic for things that aren't even networking)
17:06:11 <Qalthos> Alright, that brings us to the end of the agenda.
17:06:40 <Qalthos> Have a good week, everyone
17:06:45 <Qalthos> #endmeeting