16:00:47 <Qalthos> #startmeeting Network Working Group
16:00:47 <zodbot> Meeting started Wed Aug 29 16:00:47 2018 UTC.
16:00:47 <zodbot> This meeting is logged and archived in a public location.
16:00:47 <zodbot> The chair is Qalthos. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:47 <zodbot> The meeting name has been set to 'network_working_group'
16:01:23 <Qalthos> #topic Core Status
16:01:55 <Qalthos> #info core is frozen as of last week
16:02:11 <Qalthos> #info commuinity modules freeze tomorrow
16:03:50 <Qalthos> Here are some of the things the team has been working on this past week
16:04:30 <Qalthos> * vyos and junos cliconf bugfixes
16:04:45 <Qalthos> * fixes for nxos_system and nxos_banner
16:05:39 <Qalthos> * ios & iosl2 platform bug fixes
16:06:25 <Qalthos> * working with firepower to get ftd roles and connection in for 2.7
16:06:42 <Qalthos> #topic Agenda
16:06:59 <Qalthos> #link https://github.com/ansible/community/issues/247 is the agenda, as always
16:07:51 <Qalthos> I don't see anything on here that hasn't been discussed or acted on yet
16:08:31 <Qalthos> #topic Open Floor
16:08:57 <lindsayhill_> Only thing I was going to mention was that I'm not going to be able to get voss_config done before module freeze. :(
16:08:57 <Qalthos> Anyone have something they want to cover?
16:09:02 <bdowling> Was there a meeting last week?  I wanted to answer any questions on 35817
16:09:25 <Qalthos> lindsayhill_: That's unfortunate :(
16:10:15 <lindsayhill_> Yeah. I've gotten a bit stuck with handling the 'flat' config style that VOSS uses. flat configs - that is, no indentation under "interface blah"
16:10:21 <Qalthos> bdowling: last week was https://meetbot.fedoraproject.org/ansible-network/2018-08-22/ansible_network_working_group.2018-08-22-16.07.log.html
16:11:06 <lindsayhill_> But the lines under "interface blah" *are* context-sensitive, until the next 'exit' line. I'm sure it _can_ be handled, but probably needs to extend NetworkConfig
16:11:40 <lindsayhill_> I thought I had things working well, then realized when doing some testing that I really didn't. Heh.
16:15:05 <bdowling> @qualthos, ah, there seems to be a few different groups for the archives, I was looking at https://meetbot.fedoraproject.org/sresults/?group_id=network_working_group&type=team
16:15:50 <Anil_Lenovo> Quathos: I have 2 PRs pending. One which u have reviewed PR#44398, was pending on license issue. License issue got resolved. Now that can be merged.
16:16:02 <Qalthos> bdowling: Ah, that would work if we collectively managed to call the meeting the same thing every week
16:17:05 * Qalthos issues a general, friendly reminder that my name has no 'u' in it
16:17:34 <bdowling> Oops, finger habit :)
16:18:05 <Anil_Lenovo> Yeah.. I sorry. Its just a typo as after q, u comes always
16:18:05 <Qalthos> bdowling: I'm not personally familiar with the PR in question, but it seems most of the issues have been resolved, so I'll ping people to try to get some movement there
16:19:01 <Qalthos> #action Qalthos see what needs to be done for #35817
16:19:15 <Qalthos> #topic Lenovo
16:19:25 <Anil_Lenovo> Yes
16:19:59 <Anil_Lenovo> 2 PRs #44398 and #44559
16:20:46 <Anil_Lenovo> Qalthos: You may merge first one as License issue got resolved after my legal team mailed Gundalow
16:21:21 <Anil_Lenovo> i think the second one will be looked by Gundalow
16:21:39 <Qalthos> Anil_Lenovo: Right, so I am not anything resembling a lawyer, but the discussion does raise some issues. The biggest problem with this is it is a one-off solution for this PR and does not address any of the other code that has already been merged
16:21:59 <Qalthos> Which even includes your other PR, even though it probably shouldn't
16:23:08 <Qalthos> If this is the path we're taking moving forward for this problem, I'd like to see that license applied to all the other code that's been brought in before we move any further on these PRs
16:23:33 <Anil_Lenovo> yes.. as David Kasberg is no more associated with Lenovo and retired, the licensing issue doesnt matter
16:24:59 <Qalthos> Again, not a lawyer, but if your legal team agrees that this is a problem for this chunk of code, it is likely a problem for every other piece of code being moved in this way
16:26:01 <Anil_Lenovo> They says that there is no problem, I am free to move. That has been conveyed to John by mail. So he seems Ok with it
16:26:31 <Qalthos> If that is the case, then I would like some record of that in the PR
16:26:46 <Anil_Lenovo> Let me check, if not, I will copy it to u as well
16:27:08 <Qalthos> If Lenovo is happy with the relicense, you shouldn't need to add the license in the PR as you have
16:27:39 <Qalthos> All that aside, if we can talk about 44559 for a minute
16:27:50 <Anil_Lenovo> sure
16:28:12 <Qalthos> You have changes to cnos_rollback in a PR supposedly dedicated to integration tests
16:28:44 <Anil_Lenovo> yeah.. that may go off by refactoring I guess
16:28:46 <Qalthos> If that were not in there, this PR would have been merged this morning, as it is, it got mired in the license issue
16:29:03 <Anil_Lenovo> How to remove that 2 files..
16:30:25 <Qalthos> It looks like if you just remove the first two commits, that will probably fix everything. Are you comfortable with git rebase? it should not be a terribly difficult task in this case
16:31:06 <Qalthos> Alternately, copy versions of those files from devel and make a new commit that reverts the contents
16:31:25 <Qalthos> that one is probably way easier and more likely to work
16:31:40 * Qalthos has a bad habit of reaching for the complicated solution first
16:32:10 <Anil_Lenovo> yes.. The mistake i did is that the licensing PR I have done directly from devel, and this is from a branch
16:32:57 <Qalthos> You can checkout a new copy of devel, or even just download the files from GitHub
16:33:17 <Anil_Lenovo> ok.. will do so
16:33:42 <Qalthos> Just make sure you have the changes you've already made saved somewhere so you don't have to redo it later (:
16:33:51 <Anil_Lenovo> sure
16:33:52 <lindsayhill_> There's always some sequence of git commands that can 'fix' it...but sometimes it's easier to just start clean & copy files across
16:34:18 <lindsayhill_> I think there's an XKCD about this somewhere. Personally I rely on ohshitgit.com
16:35:02 <Qalthos> #action Anil_Lenovo clarify result of licensing issue in 44398 so we have a clear path forward for this code
16:35:31 <Qalthos> #action Anil_Lenovo Remove changes to cnos_rollback from 44559
16:35:37 <Anil_Lenovo> Qalthos : please share your email id so that I can forward you the mail from my legal team
16:35:46 <Qalthos> And then I think we can move on
16:35:53 <Anil_Lenovo> sure
16:37:04 <Qalthos> #topic Open Floor
16:37:16 <Qalthos> Anyone else want to bring something up?
16:37:56 <yaplej> I would like to see if someone could look at #38420 and PR44001.
16:38:10 <Qalthos> sure
16:38:47 <yaplej> also related issue 43861 was beyond me for a real fix.
16:40:01 <Qalthos> #topic ios_config macros
16:43:22 <bdowling> yaplej -- kind of annoying that cisco doesn't indent those macro blocks, they really should follow a block model.
16:43:52 <Qalthos> yaplej: 44001 seems sensible enough, I'll see that this gets followed up on
16:46:03 <Qalthos> #action Qalthos Make sure someone reviews 44001
16:46:41 <ganeshrn> bdowling: imo it is too late in release cycle to merge this PR 35817
16:46:54 <Qalthos> yaplej: And yes, I have no idea what we can do about 43861
16:47:04 <ganeshrn> i am +1 to merge it at start of 2.8 dev cycle so that it get enough time to uncover and fix any side effects arising due to this change
16:48:18 <ganeshrn> yaplej: it is in my todo list
16:49:00 <bdowling> ganeshrn: understood.  I didn't get time to dig into that last issue it saw in testing.  not clear exactly where connection options get initialized or it was just an issue from unit test environment..
16:49:23 <ganeshrn> will add a fix in module_utils/ios to not ignore "#macro" since it is a platform specific stuff
16:50:07 <ganeshrn> bdowling: it get's initialised in bin/asnible-connection for network_cli
16:50:22 <Qalthos> ganeshrn: Thank you for sweeping in and solving all of my problems at the last moment
16:50:42 <ganeshrn> just finished my dinner :)
16:50:52 <Qalthos> And on that note
16:50:57 <Qalthos> #topic Open Floor
16:51:18 <Qalthos> Last call for anything anyone wants to bring up for the meeting
16:51:58 <bdowling> Qalthos: and ganeshrn: #44463 -- curious on your thoughts re: prompt matching.  I hate to keep coming back to this, but feel the prompt regex is a serious issue (the tasks/connection really should have confidence it is issuing the commands at the right spot)..
16:52:59 <ganeshrn> bdowling: yes agreed it is annoying ...we had a discussion internally on this
16:53:22 <ganeshrn> currently exploring options to fix it in more robust way
16:53:43 <ganeshrn> for ios on some device the prompt is not prefixed with '\n'
16:53:54 <ganeshrn> that's the main reason for this issue
16:54:52 <bdowling> really?  that's odd.  I only saw a couple issues pointing at that, so didn't understand where that occurs.
16:55:13 <ganeshrn> one option explored is to make `terminal_stdout_re` in terminal plugin configurable
16:55:55 <ganeshrn> bdowling: https://github.com/ansible/ansible/issues/44463#issuecomment-414766830 check this comment
16:58:04 <bdowling> ? that's showing where it mis-identified a prompt?
16:58:31 <ganeshrn> and this one https://github.com/ansible/ansible/issues/38732#issuecomment-381962805
16:59:15 <ganeshrn> 2018-08-21 13:40:26,116 p=11205 u=pffs |  -- _find_prompt -> self._matched_prompt: Pri>  --
16:59:25 <ganeshrn> ^^ is the misplace prompt
17:00:18 <bdowling> In 38732 -- is that not just the case that it is the first prompt the device printed and there is no banner? So all the device prints when you connect is the first prompt?
17:00:51 <bdowling> To get around that we could 'echo HELLO' ;)
17:02:42 <ganeshrn> is it only for the first prompt?
17:03:02 <bdowling> It seemed to occur right after login in the log.
17:03:41 <ganeshrn> yes in the logs he shared that seems to be the case
17:04:08 <ganeshrn> but in comment he mentions there in proper pattern to this
17:04:24 <ganeshrn> no*
17:08:56 <Qalthos> Well, thanks everyone for coming
17:08:59 <Qalthos> We're quite a bit over time, so I'm going to close the meeting before I forget
17:09:06 <Qalthos> #endmeeting