15:00:07 <thaumos> #startmeeting ansible core
15:00:07 <zodbot> Meeting started Thu Nov  2 15:00:07 2017 UTC.  The chair is thaumos. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:07 <zodbot> The meeting name has been set to 'ansible_core'
15:00:26 * gundalow waves
15:00:32 <thaumos> #chair gundalow
15:00:32 <zodbot> Current chairs: gundalow thaumos
15:00:41 <gundalow> oh, I added something to the agenda, though I'll be back in a couple of mins
15:00:51 <thaumos> heh, ok
15:02:29 <ryansb> heya
15:02:34 <thaumos> #chair ryansb
15:02:34 <zodbot> Current chairs: gundalow ryansb thaumos
15:02:35 <thaumos> hit there
15:02:54 <gundalow> back
15:02:58 <thaumos> wb
15:04:32 <thaumos> so how are you both today?
15:04:54 <gundalow> Good thanks
15:05:08 <gundalow> If more people appear we can discuss $topic
15:05:13 <thaumos> yep
15:06:09 * Qalthos 🌊🌊
15:06:16 <thaumos> #chair Qalthos
15:06:16 <zodbot> Current chairs: Qalthos gundalow ryansb thaumos
15:07:06 <ryansb> pretty good man - raining from clouds
15:09:29 * Pilou waves
15:09:39 <thaumos> #chair pilou
15:09:39 <zodbot> Current chairs: Qalthos gundalow pilou ryansb thaumos
15:09:54 <thaumos> feels like it's going to be a rough Thursday.
15:11:36 <thaumos> #topic fix for include_role unit tests
15:11:44 <thaumos> #link https://github.com/ansible/ansible/pull/31920
15:11:54 <thaumos> Pilou: this is your's
15:12:11 <Pilou> yep
15:12:31 <thaumos> anything specific you wanted to discuss?
15:14:28 <Pilou> no
15:14:32 <bcoca> he, just had someone report that templating on include/import_roles is not working
15:14:41 <thaumos> #chair bcoca
15:14:41 <zodbot> Current chairs: Qalthos bcoca gundalow pilou ryansb thaumos
15:15:09 <gundalow> #action jimi|ansible to review https://github.com/ansible/ansible/pull/31920 as he made the original changes
15:16:01 <gundalow> bcoca: Any thoughts on it?
15:16:11 <gundalow> Otherwise I guess we can go to Open Floor
15:16:23 <bcoca> need to fix the bug before i can update the test
15:17:04 <abadger1999> Ola
15:17:10 <thaumos> #chair abadger1999
15:17:10 <zodbot> Current chairs: Qalthos abadger1999 bcoca gundalow pilou ryansb thaumos
15:17:21 <thaumos> @bcoca, looks like this bug should be fixed in 2.4.2, right?
15:17:26 <Pilou> bcoca: I found #31920 while fixing #32021
15:20:05 * jimi|ansible looks at that PR
15:20:29 <jimi|ansible> i thought i had fixed a lot of those originally
15:21:06 <bcoca> i was also under same impression, but tima just told me otherwise
15:21:46 <bcoca> https://gist.github.com/bcoca/acbb85fcddede006ea23a343bef6ed94
15:22:03 <bcoca> ERROR! Could not find specified file in role: tasks/{{mytasks}} <=
15:23:07 <Pilou> about #31920, the original changes are ok, but related unit tests are not reliable
15:27:55 <thaumos> so, to recap... seems like we need to fix the currently reported bug before this test can do anything.
15:28:31 <thaumos> @bcoca, can we consider this bug as a blocker for 2.4.2?
15:28:35 <thaumos> or is it s 2.4.3 thing?
15:29:06 <bcoca> i would consider it a blocker .. but only if we have a fix
15:29:29 <bcoca> specially since it is broken in 2.3 also
15:31:56 <thaumos> well, since they are preview, imo they aren't really blockers.
15:32:10 <abadger1999> <nod>
15:32:12 <abadger1999> Nice to have
15:32:41 <abadger1999> Priority nice to have but I won't block release if it isn't fixed.
15:34:46 <gundalow> Anything left to discuss on this?
15:35:29 <gundalow> #agreed Not a blocker as: 1) It's a preview, 2) was broken in 2.3
15:36:11 <abadger1999> #action jimi|ansible to look at fixing the underlying bug
15:36:28 <abadger1999> jimi|ansible:, Pilou ^ I assume that's right?
15:37:11 <Pilou> yep
15:37:17 <abadger1999> thaumos: Rooms gone dead.  Next topic
15:37:18 <thaumos> sorry, I was poking around to find issues opened on this.
15:37:20 <jimi|ansible> the PR looked fine so I merged it, if there's another underlying bug we can fix that as well
15:37:22 <thaumos> my bad
15:37:30 <abadger1999> #undo
15:37:30 <zodbot> Removing item from minutes: ACTION by abadger1999 at 15:36:11 : jimi|ansible to look at fixing the underlying bug
15:37:49 <abadger1999> #info PR merged.
15:37:56 <Pilou> thanks !
15:37:58 <abadger1999> jimi|ansible:  Should I cherry-pick it now?
15:38:05 <jimi|ansible> sure
15:38:22 <abadger1999> Cool.  We're done with this topic
15:38:34 <gundalow> #topic overloaded --ask-pass
15:38:38 <thaumos> #topic do we need a new cli arg to unlcok ssh key
15:38:48 <gundalow> #link https://github.com/ansible/community/issues/273#issuecomment-341108984
15:38:50 <thaumos> sorry
15:39:02 <gundalow> #info Background discussion https://github.com/ansible/ansible/issues/31988
15:39:08 <gundalow> #info We are overloading --ask-pass, sometimes it means:
15:39:15 <gundalow> #info a) Use this password to unlock an encrypted SSH Key
15:39:20 <gundalow> #info b) Use this for password auth
15:39:28 <gundalow> #info QUESTION: Do we need a new command line argument that's only used to unlock the SSH Key?
15:39:32 <gundalow> Thoughts?
15:40:00 <bcoca> https://github.com/ansible/ansible/issues/32503
15:40:36 <bcoca> ^ @jimi|ansible
15:41:28 <alikins> #31988 is similar to a recent discussion about generalizing the --ask-*-pass handling
15:42:22 <gundalow> Yup
15:42:43 <abadger1999> gundalow: So it sounds like we can't have two separate arguments when using paramiko?
15:43:00 <abadger1999> I suppose paramiko could try to connect twice...
15:43:16 <abadger1999> as a workaround
15:43:29 <abadger1999> bcoca: ^ Would that work (as you looked at the paramiko api)
15:43:48 <bcoca> not really, once you pass a ssh pass, it will use it both ways
15:44:18 <bcoca> ^ i updated the paramiko connection docs to reflect this
15:45:07 <abadger1999> gundalow: what is the bug?  Is paramiko consuming the ssh pass to unlock the key and then not using it for ssh auth?
15:45:16 <gundalow> Wouldn't look_for_keys=False fix this?
15:45:19 <bcoca> no, it will fallback
15:45:23 <bcoca> gundalow: no
15:45:31 <abadger1999> gundalow: or is it erroring when attempting to unlock the key?
15:45:43 <bcoca> look keys just stops ansible from looking for  'default locations' but if you pass in a keyfile, it will still do this
15:45:55 <bcoca> abadger1999: no error, if it cannot decrypt key it will use as ssh password
15:45:56 <gundalow> How can I connect to a machine using a passphrase when there are also keys available
15:46:00 <alikins> to me, I'd like all of the --ask-*-pass to set up a (not-ansible-specific) callback to be called when it is needed. The main complication is interactive prompts want stdin/stdout, but sometimes the callbacks wouldn't get called until in a worker process. if we could work around that (always call them before starting a worker?) it should make it easier to handle things like ssh-key-pass vs ssh-pass
15:46:21 <abadger1999> bcoca: There is a bug, though... trying to ask what that is: https://github.com/ansible/ansible/issues/31988
15:47:06 <bcoca> abadger1999: the bug was that we did not document nor tell the user when this happens, you can only really hit this issue if your passhprase == ssh password
15:47:24 <alikins> but then, things like the ssh connect/auth state machine kind of have to be in the worker
15:47:39 <bcoca> alikins: the problem with that is 200 hosts prompting
15:47:52 <gundalow> privateip: You around?
15:47:57 <bcoca> we would need to institute tty locking, like debug, but this changes engine behaviour
15:49:10 <bcoca> https://github.com/ansible/ansible/pull/31024/files#diff-f24f238727907014621e8c7a84a5644dR47 <= my update to password docs in paramiko
15:50:00 <alikins> but maybe connection plugins need to support an auth callback api, possibly via IPC.  But I don't really want to accidentally re-implement PAM
15:50:12 <bcoca> http://docs.paramiko.org/en/2.3/api/client.html
15:50:46 <bcoca> alikins: that was one reason i was thinking of forking the stdout callback to handle out tty interaction and use multiproc queues to send/recieve events/input
15:52:05 <bcoca> that way we avoid the 'debug lock issue' and still ensure serialization at one point, the queue acts as a stack
15:52:15 <alikins> though my temptation is just to document 'please, just use ssh-agent, I beg you'
15:52:25 <abadger1999> "the queue acts as a stack"
15:52:38 <abadger1999> Allan Turing is turning over in his grave right now.
15:52:52 <abadger1999> ;-)
15:53:04 <bcoca> youknowwhatimeant
15:53:32 <gundalow> Well, misspelling peoples names generally does irk them
15:53:41 <alikins> abadger1999:  hey, it's true for N items where N=0,1.  I'm sure it's okay for the rest...
15:53:56 <abadger1999> :-)
15:54:07 <abadger1999> gundalow: hah.  that too.
15:54:19 <abadger1999> At least I didn't misspell both names
15:54:26 <gundalow> :D
15:54:34 <bcoca> Allan Truning?
15:54:59 <orc_fedo> @alikin might some 'ssh-agent' configuration be useful here?
15:55:54 <bcoca> going back to problem at hand, this is moslty user being 'suprised' by a behaviour (to be fair so was I, did not know paramiko did this), I think documenting it shoudl be good enough
15:55:54 <abadger1999> So.... is there actually anything to do here?
15:56:19 <bcoca> 99% of peopel wont hit this and only 1% of those hitting it will notice/care they used ssh key instead of ssh pass
15:56:50 <abadger1999> bcoca: Hmm... is the bug that you can't have ssh key passphrase == login passphrase on the remote machine?
15:56:56 <bcoca> i think that updating docs is enough ... someone will want ssh plugin to have feature parity
15:57:05 <abadger1999> bcoca: if so, your doc update still doesn't highlight that problem
15:57:09 <gundalow> I think only docs improvements for 2.5
15:57:15 <thaumos> agreed on documenting this
15:57:25 <bcoca> abadger1999: no, the problem is that 'we dont tell user we used key instead of ssh login when both use same password'
15:57:42 <abadger1999> bcoca: okay... but then why is the user's task failing?
15:59:00 <bcoca> cause cisco does not allow key auth, but since we successfully decrypted key .... paramiko uses key
15:59:20 <bcoca> ^ this is very much an incredebly narrow corner case
15:59:56 <bcoca> a) ssh key must be provided b) target must no accept ssh key c) passphrase for key must be same as ssh login password
16:00:48 <bcoca> d) must be using paramiko (which is true for most networking)
16:02:08 <thaumos> alright folks, we need to close the meeting out in a minute or so
16:02:13 <abadger1999> gundalow: ^ So that seems like the documentation is more of a FAQ entry
16:02:28 <bcoca> probably both
16:02:38 <alikins> I guess you could retry without any keys, just password to workaround that case, but... ewww.
16:02:39 <thaumos> I think both
16:02:55 <abadger1999> thaumos: <nod>  We can close meeting and continue in #ansible-devel
16:03:03 <thaumos> k, cool
16:03:05 <thaumos> #endmeeting