16:02:33 <pabelanger> #startmeeting Ansible Network working Group
16:02:33 <zodbot> Meeting started Wed Sep 11 16:02:33 2019 UTC.
16:02:33 <zodbot> This meeting is logged and archived in a public location.
16:02:33 <zodbot> The chair is pabelanger. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:33 <zodbot> The meeting name has been set to 'ansible_network_working_group'
16:02:46 <pabelanger> #chair ganeshrn ikhan tributarian dmellado Qalthos
16:02:46 <zodbot> Current chairs: Qalthos dmellado ganeshrn ikhan pabelanger tributarian
16:02:54 <pabelanger> #topic Core Updates
16:03:14 <pabelanger> ansible 2.9 is well underway, last week we had 2.9.0b1 release
16:03:35 <pabelanger> I _think_ there maybe be b2, otherwise we'll start into rcs
16:03:40 <Qalthos> #unchair tributarian
16:03:40 <zodbot> Current chairs: Qalthos dmellado ganeshrn ikhan pabelanger
16:04:03 <pabelanger> please test, and report back any issues :)
16:04:31 <pabelanger> #link https://docs.ansible.com/ansible/latest/roadmap/ROADMAP_2_9.html if you want to learn more about the release schedule
16:04:39 <pabelanger> #info AnsibleFest is Sept 24-26 in Atlanta, GA
16:05:03 <pabelanger> this is coming up fast, rumor is a lot of people going
16:05:09 <Qalthos> #info There will be no IRC meeting that week
16:05:23 <pabelanger> If you can make it, that would be great
16:05:44 <pabelanger> otherwise, what Qalthos said, we'll be having some network related things in Atlanta too
16:05:58 <pabelanger> #info Contributor Summit is happening the day before, Sept 23
16:06:11 <pabelanger> we'll also be doing a thing before the conference starts
16:06:22 <pabelanger> #link https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-networking is the agenda
16:06:31 <pabelanger> if you'd like to discuss something specific, please add it
16:07:15 <Qalthos> gundalow also put a whole bunch of info about the summit in the meeting agenda
16:08:08 <pabelanger> #link https://etherpad.openstack.org/p/ansible-summit-atlanta-2019 is the top-level page, with other items outside of network
16:08:21 <pabelanger> okay, lets get started for today
16:08:24 <pabelanger> As for the agenda for this meeting, it can always be found at https://github.com/ansible/community/labels/network
16:08:25 * gundalow waves
16:09:11 <pabelanger> #topic meraki changes
16:09:14 <Qalthos> #chair nilashishc gundalow
16:09:14 <zodbot> Current chairs: Qalthos dmellado ganeshrn gundalow ikhan nilashishc pabelanger
16:09:22 <pabelanger> this one is from mrproper
16:10:15 <pabelanger> I don't see any specific PRs linked, mrproper do you mind sharing
16:10:16 <mrproper> Morning/afternoon everyone. In Ansible 2.9 I added a feature to `meraki_organization` which allows for deleting an organization. Organizations are the top level structure which ALL objects related to the environment roll up to. This is basically `rm -rf /*` for Meraki.
16:10:20 <mrproper> I don't have any PRs yet.
16:10:36 <pabelanger> ack
16:10:40 <mrproper> The feature is in 2.9. But the more I think about it, the more terrifying it is as a simply copy/paste or typo will be catastrophic to the organization.
16:11:16 <pabelanger> yah, we've had these discussions around mgmt interfaces too on applinaces, if you deleted that or replaced it, it would nuke the box access
16:11:16 <mrproper> I've updated documentation basically saying "This is a loaded gun, be amazingly careful" but we know people don't read documentation and it would be a "resume generating event".
16:11:51 <pabelanger> Yah, i think that is mostly all you can do
16:11:55 <mrproper> What I'd like to do is add a confirmation parameter (maybe `deletion_confirmation`) so if it's `state: absent` it will still fail unless they manually add it.
16:11:57 <pabelanger> aside from deleting the functionality
16:12:25 <mrproper> However, this feature is still in 2.9 without the safety parameter. And I know we're at beta and I'm sure it's frowned upon, but is there ANY chance if I get a PR in tonight that we can merge it into 2.9 to help someone not be fired?
16:13:12 <Qalthos> mrproper: The only change you're likely to get in to 2.9 about this is taking out `state: absent`
16:13:41 <mrproper> Qalthos: I think I'm okay with removing the feature until 2.10 since it's so dangerous. Agree?
16:14:13 <mrproper> This topic also relates to a similar question...how much risk is Ansible comfortable with putting into the modules? Is what I'm doing, without a safety acknowledgement, too much risk?
16:14:49 <pabelanger> For me, as long as it is documented, I think that is most important
16:14:53 <Qalthos> We don't really have much about that sort of thing as far as I'm aware.
16:15:01 <pabelanger> like you said, there is a lot of things in ansible that is a foot cannon
16:15:21 <mrproper> Who do I talk to about getting the feature removed in 2.9?
16:15:22 <Qalthos> `file` lets you remove any file you have write access to without asking twice
16:16:05 <Qalthos> mrproper: open a backport PR removing the option
16:16:13 <pabelanger> we also need a changelog entry
16:16:16 <mrproper> Perfect. Thank you!
16:16:27 <mrproper> I'm okay with the next topic if you are.
16:16:50 <pabelanger> review unit tests?
16:16:52 <mrproper> Yes.
16:16:58 <pabelanger> go for it
16:18:24 <mrproper> Qalthos: You have said there is now a very strong preference for unit tests on new modules. I've been adding unit tests to the new module PRs I have in my queue and am full thumbs up there. However, I'd like to better understand what are the expectations of unit test coverage within the new module as compared to integration test coverage. For example, some of my modules don't have any functions outside of
16:18:24 <mrproper> `main()` or whatever it happens to be called. So unit tests would require mocking many objects and seem to be a better fit for integration.
16:20:03 <Qalthos> We want unit tests because otherwise we have no way of verifying test results.
16:20:42 <mrproper> So you would want to see a unit test for the entire module execution?
16:22:44 <pabelanger> The more code coverate the better, but something is better then nothing
16:23:15 <pabelanger> intergation tests are also nice, but I think that is much harder in this case with a service
16:23:17 <Qalthos> We would like to see unit tests for whatever amount of functionality makes sense. Generally for the modules we write, that involves mocking the transport and ensuring that the correct messages are sent to the device and that the correct status is inferred from the response
16:23:49 <mrproper> Okay that's good guidance. Thank you. I think I'm through for today!
16:24:26 <pabelanger> great
16:24:34 <pabelanger> let move to next topic then
16:24:56 <pabelanger> #topic exos vlan resource module
16:25:04 <UjwalKomarla> Hi..
16:25:07 <pabelanger> UjwalKomarla: this looks to be your topic
16:25:12 <UjwalKomarla> That's right.
16:25:25 <pabelanger> #link https://github.com/ansible/ansible/pull/61865
16:25:32 <UjwalKomarla> I see that ganeshrn self-assigned the PR..
16:25:34 <Qalthos> ganeshrn has signed on to review this module, and I've started reviewing as well
16:25:35 <pabelanger> #link https://github.com/ansible/ansible/pull/51364
16:26:21 <pabelanger> okay great, so this one looks to be under control
16:26:33 <UjwalKomarla> So, for exos_vlans I'll wait for review comments and update as required..
16:26:35 <pabelanger> it is also neat to see RMB being used by community
16:26:38 <Qalthos> This isn't your first, so I'm not expecting any issues... the builder does a lot of the work
16:26:57 <UjwalKomarla> That's right, RMB is helping us get work done sooner..
16:27:19 <UjwalKomarla> Already have a third module in the works. exos_lldp_interfaces - https://github.com/ansible/ansible/pull/62108
16:28:10 <UjwalKomarla> My next review request is on https://github.com/ansible/ansible/pull/51364 - Don't fail if exos can't configure cli columns
16:29:26 <pabelanger> okay great, looks like you are making good progress using RMB
16:29:31 <UjwalKomarla> The issue was regarding the usage of 'display' for a persistent connection.
16:29:33 <Qalthos> Oh, I have a review that was never submitted...
16:29:35 <Qalthos> ooops
16:29:50 <Qalthos> yeah, refresh that page
16:29:51 <UjwalKomarla> Ah!
16:30:33 <Qalthos> I wrote that months ago, but never hit the "Request Changes" button
16:30:41 <UjwalKomarla> Great. Thanks. Will wait on zombah to update.
16:31:12 <UjwalKomarla> It slipped through me as well.
16:32:25 <UjwalKomarla> My next item is about this PR: https://github.com/ansible/ansible/pull/61914
16:33:02 <UjwalKomarla> In this review, I'm trying to have a single action file for all of exos modules.
16:33:37 <UjwalKomarla> ansible-test sanity --test action-plugin-docs reports a failure 'action plugin has no matching module to provide documentation'
16:35:15 <pabelanger> I think for that, we need to update ansible-test some how
16:35:45 <pabelanger> UjwalKomarla: we can as in #ansible-devel, and see what they say
16:35:52 <pabelanger> I just don't know of the top of my head
16:36:04 <UjwalKomarla> Ok. I will do that.
16:36:13 <pabelanger> great
16:36:27 <UjwalKomarla> I have one more query on the same PR
16:36:38 <pabelanger> go for it
16:37:11 <UjwalKomarla> There is a 'CONNECTION_FACTS_MODULES' object with description of "Which modules to run during a play's fact gathering stage based on connection"
16:37:29 <UjwalKomarla> Is this related to the usage of 'gather_facts' in the playbook?
16:38:05 <UjwalKomarla> I tried to add 'exos_facts' to the list. But, I did not see any change in the facts gathered.
16:38:19 <UjwalKomarla> I am not sure what I am missing.
16:38:40 <pabelanger> I'll have to defer to Qalthos on that
16:39:20 <Qalthos> I actually don't know anything about that
16:39:27 <Qalthos> I'll look into it, though
16:39:57 <UjwalKomarla> Yes please. Any guidance will be great.
16:40:13 <UjwalKomarla> Do you want me to tag you on the PR?
16:42:20 <Qalthos> Is that 61914?
16:42:31 <UjwalKomarla> Yes.
16:43:08 <Qalthos> I've got it then
16:43:26 <UjwalKomarla> Great.
16:43:40 <UjwalKomarla> I'm done with my items for the meeting.
16:43:51 <UjwalKomarla> Thanks
16:44:15 <pabelanger> great
16:44:41 <pabelanger> #topic PR#60569
16:44:48 <pabelanger> #link https://github.com/ansible/ansible/pull/60569
16:44:59 <pabelanger> xuxiaowei0512-: this looks to be from yourself
16:45:13 <xuxiaowei0512-> yes
16:45:23 <xuxiaowei0512-> A small PR
16:45:33 <xuxiaowei0512-> Just 3 lines
16:45:40 <Qalthos> pabelanger: I don't think we could touch it even if it weren't
16:45:41 <xuxiaowei0512-> Please give me a hand
16:45:58 <pabelanger> yah, I believe our hands are still tied here unfortantly
16:46:36 <xuxiaowei0512-> Automerge does not work for it.
16:47:01 <xuxiaowei0512-> But ask help from there.
16:47:20 <pabelanger> have you checked with ansible-devel on why that is?
16:47:23 <pabelanger> automerge not working
16:47:56 <Qalthos> pabelanger: because it's not a module
16:47:56 <xuxiaowei0512-> This is a common file, not a module.
16:48:07 <pabelanger> ah, okay.
16:48:12 <xuxiaowei0512-> Yeah
16:48:26 <pabelanger> yah, in this case, I think you are blocked until we get approval again to look
16:49:01 <xuxiaowei0512-> '=(
16:51:09 <pabelanger> Agree
16:51:14 <pabelanger> #topic Open discussion
16:51:24 <pabelanger> if there is anything else people would like to discuss we can now
16:52:43 <Qalthos> One more meta item, I'm planning on rotating the agenda again after AnsibleFest
16:53:19 <Qalthos> So that it doesn't get 300 replies deep again
16:54:10 <Qalthos> And I generally plan on doing that moving forward roughly once a year
16:55:11 <Qalthos> So the agenda will still be at https://github.com/ansible/community/labels/network just not necessarily the same issue
16:55:53 <pabelanger> ++
16:59:29 <pabelanger> thanks everybody
16:59:31 <pabelanger> #endmeeting