15:02:14 <jimi|ansible> #startmeeting Public Core Meeting
15:02:14 <zodbot> Meeting started Thu Oct 20 15:02:14 2016 UTC.  The chair is jimi|ansible. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:14 <zodbot> The meeting name has been set to 'public_core_meeting'
15:02:25 * gundalow waves
15:03:19 <thaumos> gm
15:03:29 <thaumos> and afternoon
15:03:31 <jimi|ansible> #chair gundalow abadger1999 bcoca jtanner jtanner|t420 mattclay ryansb thaumos
15:03:31 <zodbot> Current chairs: abadger1999 bcoca gundalow jimi|ansible jtanner jtanner|t420 mattclay ryansb thaumos
15:03:39 <jtanner> hello
15:03:40 <gundalow> \o/
15:03:45 <alikins_also> bloop
15:03:47 <jimi|ansible> #topic Persistent Connnections
15:03:54 <nitzmahone> blar
15:03:58 <jimi|ansible> #chair alikins_also
15:03:58 <zodbot> Current chairs: abadger1999 alikins_also bcoca gundalow jimi|ansible jtanner jtanner|t420 mattclay ryansb thaumos
15:03:59 <gundalow> #topic Changing Agenda format
15:04:12 <jimi|ansible> o_O
15:04:25 <gundalow> I'd like to propose that we have standing agendas, rather than one per meeting*
15:04:31 <gundalow> *when we remember to create them
15:04:34 <jtanner> gundalow: is that what you put in slack this morning?
15:04:43 <gundalow> *or multiple that when we forget to close them
15:04:46 <gundalow> jtanner: correct
15:04:51 <ryansb> In GH issues still?
15:04:56 <gundalow> yup
15:04:59 <jimi|ansible> i'm fine with that
15:05:13 <jtanner> makes it easier ... until we get 1000 comments deep
15:05:22 <jimi|ansible> create a .rst for it and modify it via PRs?
15:05:35 <gundalow> For example, if you look at https://github.com/ansible/community/issues/110 I just ~~strikethrough~~ and add a comment, such as "merged", or  discussed and we agreed to do X
15:05:38 <bcoca> no more PRs, we can barely merge the ones we have
15:05:39 <abadger1999> ola
15:05:56 <jtanner> use the github wiki then
15:05:59 <nitzmahone> Standing issue is prob fine so long as we also remember to update/cross off items, and probably need to cycle it when it gets too big.
15:06:11 <bcoca> the other option is using the 'projects' category for each meeting
15:06:17 <gundalow> GitHub issues mean anyone can add stuff. and people with powers can edit existing comments to strike through
15:06:37 <jimi|ansible> bcoca: that might work, though non-contribs can't edit or comment on them can they?
15:06:49 <gundalow> I like GitHub issues as it's easy to link from PRs/Issues/Commits - and you see the link on both ends
15:06:50 <bcoca> anyone can comment on a ticket
15:06:59 <nitzmahone> There's no comment threading
15:07:07 <bcoca> was mostly thinking project == meeting type
15:07:29 <bcoca> then issues in project can be 'single issue' as gundalow is proposing or 'issue per actual meeting' which is what we had till now
15:07:41 <gundalow> The issue I think needs solving is that we aren't creating/closing tickets
15:07:59 <nitzmahone> *cough* bot job *cough*
15:08:03 <bcoca> agreed, i don' t think either approach fixes that, its a discipline issue
15:08:07 * jtanner hides.
15:08:24 <gundalow> Testing Working Group; Network; New Module are work with a standing agenda ticket
15:08:28 <gundalow> https://github.com/ansible/community/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Ameeting_agenda%20
15:08:43 <gundalow> It's only the Core Meeting that's different
15:08:46 <bcoca> i propose taht whomever manages the meeting needs to update the ticket/tickets
15:08:59 <jtanner> thought that was already the case
15:09:01 <nitzmahone> That in itself has been tricky
15:09:12 <bcoca> jtanner: probably implied but i was not aware of it
15:09:26 * gundalow would like to do better things with his life than copy & pasting ~100 tickets a year for meetigns
15:10:00 <gundalow> Can we try having a standing agenda for a month and see how we get on?
15:10:06 <bcoca> gundalow:  either method of organizing does not change the volume
15:10:17 <abadger1999> gundalow: +1 seems reasonable to try.
15:10:25 <nitzmahone> wfm
15:10:41 <abadger1999> gundalow: the real test will be the first time we have to cycle to a new ticket.
15:10:42 <bcoca> ^ im not saying im against it, almost any way works for me
15:10:51 <gundalow> abadger1999: yup
15:10:57 <bcoca> open mont/year titled?
15:11:02 <bcoca> sept_2016
15:11:10 <gundalow> #action #gundalow to create meeting ticket
15:11:16 <bcoca> ^ that is probably a good medium with the approaches
15:11:20 <bcoca> or use milestone?
15:11:22 <gundalow> 2016_10
15:11:25 <jtanner> we need to hire a person to do all this busy work
15:11:33 <gundalow> #topic open floor
15:11:44 <gundalow> NEXT
15:11:48 <jimi|ansible> #topic Persistent Connnections
15:11:59 <bcoca> ^ isn't that the NEXT meeting?
15:12:00 <jtanner> privateip said he couldn't make this meeting
15:12:09 <jtanner> but we -were- supposed to talk about it here
15:12:10 <gundalow> Peter *can* make the BJ meeting
15:12:10 * bcoca x2 checks calendar
15:12:24 <jimi|ansible> we still said he wasn't absolutely required to attend, as this is an internal design thing
15:12:24 <gundalow> he's just messaged me
15:12:59 <bcoca> he is on vacation so he gets to slack off
15:13:22 <gundalow> Peter has just messaged me to say he will be running the BJ meeting we have scheduled in ~45 minutes
15:13:30 <abadger1999> s/get to/should be/
15:13:33 <bcoca> i think we all agree, this is a feature we need for simple scaling purposes, just to get that confirmed
15:13:35 <abadger1999> :-)
15:13:51 <abadger1999> bcoca: +1
15:13:52 <jimi|ansible> gundalow: i understand, however we can hash things out now or at least discuss options
15:14:05 <gundalow> OK :)
15:14:14 <bcoca> controlpersist master helps but it is not w/o issues, the connection persistance is something that is 'hidden' from ansible
15:14:14 <jtanner> i had no idea that the network modules had their own special connection method
15:14:15 <gundalow> start, and I'll record stuff in gDocs
15:14:22 <gundalow> Qalthos: you around?
15:14:27 <Qalthos> yup
15:14:31 <bcoca> jtanner: so do the cloud modules, since they basically do api calls
15:14:34 <jtanner> #chair Qalthos
15:14:34 <zodbot> Current chairs: Qalthos abadger1999 alikins_also bcoca gundalow jimi|ansible jtanner jtanner|t420 mattclay ryansb thaumos
15:14:42 <jimi|ansible> so, for those who are not on the core team, it has come up that we need some method of allowing persistent connections outside of ControlPersist for non-ssh connections
15:14:49 <jtanner> bcoca: but most people run those in "local" connection mode
15:15:07 <gundalow> Qalthos: cool, may need you to chip in with the technical detail about how networking currently works and the proposals
15:15:12 <bcoca> or for ssh connections that cannot use control persist (most network devices)
15:15:13 <jimi|ansible> this is especially useful for winrm connections, however it is also useful for other connection types like paramiko
15:15:27 <jimi|ansible> bcoca: I am so unclear about that... CP is on the master side, not the device
15:15:34 <bcoca> its on both
15:15:43 <jtanner> does winrm have a concept of a persistent open channel?
15:15:46 <bcoca> both client and server need to support it for it to work
15:16:03 <jimi|ansible> bcoca: no, i don't think so, that's why CP works to older SSH's like on EL5 which don't support it at all
15:16:09 <nitzmahone> WinRM has two different things that we could call "persistent connections"
15:16:16 <jimi|ansible> at worst, it's a KeepAlive setting that can't be modified for network devices
15:16:30 <jtanner> nitzmahone: and they can be managed by the client side?
15:16:39 <nitzmahone> Not really
15:16:44 <bcoca> jimi|ansible: they dont need to support exact same things/version, but both client and server are involved
15:17:07 <bcoca> as you need to be able to reissue a connection on the existing one (multiplexing iirc, is the requirement on the server side)
15:17:36 <jtanner> so for the paramiko side, we're basically talking about creating the channel and passing that object ref around to other tasks?
15:17:41 <nitzmahone> That's based on the current networking design that has paramiko baked directly into the modules though- not sure we want to design this feature around that
15:17:53 <bcoca> jtanner: i would say we need to make this more general
15:18:04 <bcoca> docker remote, for example, would also benefit
15:18:08 <jtanner> ansible-ssh-proxy ?
15:18:10 <bcoca> winrm, funcd, etc
15:18:13 <nitzmahone> (eg, lets' not hamstring ourselves to that model if we could come up with a saner logical connection for networking)
15:18:24 <bcoca> nitzmahone++
15:18:49 <bcoca> i would say that connection plugins try to find 'cached connection' first and use that, if not, initiate connection and pass to 'cache'
15:19:03 <bcoca> ^ cache would have to handle, invalidation, keepalive, limits, etc
15:19:09 <jtanner> privateip said something like "other projects are already doing this" ... how?
15:19:13 <bcoca> cache would have to live in main process
15:19:27 <nitzmahone> If we use paramiko as the lowest-common-denominator, we need to have some way to preserve a Python instance with an open socket connection between tasks.
15:19:45 <bcoca> jtanner: his plugins do this already at the module level, we just want to push it into the 'ansible level'
15:19:46 <gundalow> Qalthos: Do you know what/how othe projects are doing this already ( jtanner's comment above)
15:19:52 <nitzmahone> I don't think pickling/serialization out of the worker will fly in that case
15:20:00 <Qalthos> gundalow: I do not
15:20:14 <bcoca> nitzmahone: nope, thinking we pass refs to the socket/connection persistent object
15:20:16 <nitzmahone> WinRM can work in the same way, and that would be the most efficient way to do persistence there as well
15:20:26 <alikins> (re control persist, remote side sshd needs to support MaxSessions > 1)
15:20:27 <nitzmahone> I don't think that will work for WinRM though
15:20:50 <nitzmahone> (socket anyway, persistent object sure
15:21:20 <bcoca> nitzmahone: it can work for winrm, http call goes to socket instead of remote address (but that is one implementation, that is why i used /)
15:21:41 <nitzmahone> The issue I see with that without changing anything else is that we'd have to allow our # of open forks to grow to the # of hosts (even if we only use [forks] at a time)
15:22:14 <nitzmahone> ("that" being the persistent object case)
15:22:16 <bcoca> yes, file handle requirements will go up, but not much more than current usage with control persist
15:22:34 <bcoca> ^ instad of being external to ansible, it will be internal
15:22:58 <nitzmahone> The other issue with that, at least on the winrm side, is that there has to be something to keep the connection fresh if we're off servicing other hosts
15:23:06 <nitzmahone> I suspect paramiko would have the same issue
15:23:18 <bcoca> nitzmahone: which is why i mentioned that the 'cache' needs to handle keepalive
15:23:26 <bcoca> ^ conenction shared cache
15:23:41 <bcoca> keepalive, expiration and resource limits
15:24:00 <nitzmahone> I think the socket-based connection would require cooperation from the underlying system though, no?
15:24:09 <nitzmahone> (eg, pywinrm would need to understand it)
15:24:52 <bcoca> the underlying open functions should understand socket semantics, i doubt pywinrm is reimplementing those
15:25:07 <bcoca> ^ but that is too low a detail at this point
15:25:23 <nitzmahone> The "big picture" way I was thinking about this was to remove the worker creation/assignment from TQM and move it to where we do the connection lookup
15:25:48 <bcoca> why?
15:25:50 <jimi|ansible> nitzmahone: i don't think that's necessary
15:25:56 <nitzmahone> bcoca: it sounds good, but I can't see how it would work
15:26:21 <jimi|ansible> i would rather startup a forked process which workers can talk to directly over a MP queue
15:26:23 <nitzmahone> jimi|ansible: my other selfish reason for that would be to allow abstraction of the worker creation as a thread instead of a fork (though we could do that at TQM level too)
15:26:26 <bcoca> nitzmahone: dont worry about it for now, jsut mentally subsitute 'socket' for persistent connection object every time i talk
15:26:38 * bcoca likes typing less
15:27:08 <nitzmahone> I'm not convinced it's going to work for pywinrm, is the only reason I *am* worried about it
15:27:09 <bcoca> nitzmahone: you cannot really do that w/o making ansible thread safe , it isn't by a lot
15:27:27 <bcoca> nitzmahone: again, does NOT need to be a socket, its just easier to say than the alternatives
15:27:55 <bcoca> and pretty sure it can work, the amount of hacking being the only question
15:28:00 <nitzmahone> persistent connection object == lives in a dedicated Ansible fork though?
15:28:08 <bcoca> main
15:28:10 <nitzmahone> So one fork per connection
15:28:16 <bcoca> yes, just like variable manager does
15:28:38 <nitzmahone> Right except we max that out at [forks] today, right?
15:28:39 <bcoca> one fork per task, connections are handled on their own (they can even be threads)
15:28:52 <nitzmahone> Where is the persistence though?
15:29:10 <bcoca> the max out is cause we applyt it to the task fork, we dont need to apply it to connection forks
15:29:39 <nitzmahone> But right now the connection object lives in the task fork, yeah?
15:29:47 <bcoca> this is why i mention a 'connection cache', keep a reference there that can be locked and reused
15:30:06 <bcoca> ^ how most connection pooling works, pretty standard
15:30:07 <jimi|ansible> the other idea is we create a ConnectionManager (like we have for VariableManager) and that creates the connection earlier
15:30:17 <bcoca> think 'shared db connection'
15:30:18 <nitzmahone> That'd be more like what I'd advocate for
15:30:25 <nitzmahone> Standard connection pooling
15:30:27 <bcoca> jimi|ansible++ for being more articulate
15:30:37 <jtanner> why can't we just try to mimic how control persist works and exec/fork something off into the background that dies on it's own?
15:31:02 <bcoca> jtanner: either way we need a connection manager
15:31:02 <jtanner> rather than juggling crap within the play/tasks
15:31:04 <nitzmahone> We'd have to roll our own IPC
15:31:06 <jimi|ansible> jtanner: that's what i was thinking of with a background MP process, however it will depend on whether or not thinks like winrm and paramiko are pickleable
15:31:14 <nitzmahone> Assume they're not
15:31:15 <bcoca> jtanner: we dont need to touch play/tasks
15:31:15 <jimi|ansible> ^ or use shared memory
15:31:24 <jimi|ansible> which is a frigging nightmare area for python
15:31:33 <jimi|ansible> trust me, i looked into it when writing 2.0
15:31:44 <alikins> nitzamahone: so sort of a task queue and a connection pool, but connections in connections pool are also more or less task consumers
15:31:55 <bcoca> kindof, we just need to pass reference to managed connection and make sure it is locked
15:32:02 <jtanner> write a bin/ssh like thing in paramiko that can setup it's own pipes and Popen that just like we do for ssh
15:32:11 <nitzmahone> WinRM has another way to do this where we can just snarf a couple of GUIDs- it's less efficient than keeping the persistent HTTP(S) connection open, but it lets us skip a couple round trips for each task
15:32:36 <jimi|ansible> the hard part with a ConnectionManager is that right now we create connections in the TaskExecutor, which is done after all the Playbook* objects are finalized
15:32:39 <nitzmahone> We'd still have to have refresh/cleanup though, otherwise we risk hitting dead connections and/or DoSing the host.
15:32:46 <jimi|ansible> which we have to wait for, because of delegate to, variables, etc.
15:33:02 <bcoca> jimi|ansible: not hard, they can function mostly like fact cache, check if it exists in sahred, if not create it and pass ref back
15:33:19 <bcoca> the 'connection creation' itself might need to be a 'callback to the main proc'
15:33:20 <nitzmahone> There'd have to be custom per-connection code that could run in the pool selection stuff so we don't keep too many connections open (real or logical)
15:33:26 <jimi|ansible> ^ bcoca that relies too on the object ref being pickleable
15:33:47 <bcoca> not thinking about objects, but yes if we implement it that way
15:33:49 <jimi|ansible> if it is, it's easier to do this with a shared process that workers talk to over a queue
15:34:07 <bcoca> agreed
15:34:16 <bcoca> that is simplest solution
15:34:17 <nitzmahone> What's the diff if that process is main ansible or a new shared child?
15:34:24 <jimi|ansible> contention
15:34:28 <bcoca> inheritance
15:34:34 <bcoca> ^ both those things become major issues
15:34:35 <jimi|ansible> the main thread is busy sending jobs out and reading results back
15:34:41 <jimi|ansible> it's already a choke point
15:34:45 * nitzmahone curses Python concurrency
15:34:53 <jimi|ansible> unless we add another background thread like we did for reading results
15:35:16 <bcoca> it did not buy us much with results processing ...
15:35:28 <jimi|ansible> that's 50/50 with a multiprocessing.Process anyway
15:35:59 <jimi|ansible> bcoca: yeah the goal there wasn't performance, it was to ensure we didn't deadlock when all workers were busy and we hit a tight while loop waiting for workers to be available
15:36:34 <jimi|ansible> i think on some systems, the worker wasn't exiting until the result was read back by the main process, maybe some weird system stuff there
15:36:41 <jimi|ansible> never happened on my system/OS
15:36:58 <jimi|ansible> but anyway, like i said that's tomato/tomahto whether it's a thread of MP.Process
15:37:02 <jimi|ansible> s/of/or/
15:37:05 <jtanner> i still think we should just write a new bin/ssh with paramiko.
15:37:22 <nitzmahone> That's one of the reasons I was hoping to have Py3.5 only + support (so we could use the new async primitives to simplify some of that kind of stuff)
15:37:24 <bcoca> jtanner: and use same 'external' control persist?
15:37:24 <jimi|ansible> jtanner: we'd have to do so for every connection type
15:37:40 <jtanner> in this case, the urgency is for the network stuff
15:37:47 <nitzmahone> Yeah, that'd be nasty for error handling
15:37:52 <bcoca> ^ that is one shortcut implementation
15:38:00 <jimi|ansible> well, i guess we'd only need a bin/whatever for each whatever that wanted persistent connections
15:38:00 <bcoca> nitzmahone: same as it is now with cp
15:38:13 <jimi|ansible> so that's a third option
15:38:14 <jtanner> the way you guys are talking, every other idea is a lot of code change
15:38:16 <abadger1999> If we're going to reach back to the main process to get a connection, have we just turned the main process into a server?  (Liek we were talking about but rejected for optimizing vars?)
15:38:20 <nitzmahone> Right, but now we have the same suckage with every CP instead of just ssh
15:38:37 <jimi|ansible> jtanner: actually having a background process to save connections is very simple, not much code at all
15:38:38 <nitzmahone> abadger1999: that's kinda what I was thinking about that
15:38:52 <bcoca> jtanner: yes, it is, using 'bin/hepers' would keep the main codebase teh same
15:39:25 <jimi|ansible> it could actually be the same bin/<thing>, like we overload bin/ansible
15:39:33 <bcoca> abadger1999: this is why i keep using 'references', i was hoping teh connections not being that tightly coupled
15:39:38 <jtanner> those "background processes" aren't useful if i'm using bin/ansible
15:39:58 <jtanner> a bin/ssh w/ paramiko could work for that too
15:40:05 <jimi|ansible> jtanner: in that case you're executing a single task anyway, so a persistent connection doesn't help you too much
15:40:10 <thaumos> that being said, too bad we can’t have Tower act as this server on behalf of the engine
15:40:28 <jimi|ansible> thaumos: same serialization issues, and Tower itself would become a choke point
15:40:33 <nitzmahone> Let's not throw *that* kitchen sink into this pile
15:40:47 * jtanner feels compelled to waste 2 days writing his idea
15:41:04 <bcoca> actually, it does not need to become a chokepoint, having tower deal with persistence is not a bad idea
15:41:17 <bcoca> connection: tower at ansible level, it can just see 'local sockets'
15:41:23 <jimi|ansible> doesn't need to be tower, we could create any process and then it doesn't become tower specific
15:41:26 <bcoca> ^ pushes the complexity out
15:41:47 <abadger1999> i think pushing the complexit out is also the attraction of jtanner's idea.
15:41:48 <nitzmahone> jtanner: The problem I have with abstracting all the connections to a new command-line process is that I lose all the fidelity I have with calling an API right now- my error handling/recovery stuff is reduced to parsing error messages and nastiness
15:41:56 <bcoca> abadger1999: i like both
15:42:15 <nitzmahone> (just like it is with ssh today- arguably the most difficult to reason about)
15:42:19 <bcoca> nitzmahone: yes, as we do with all connections right now
15:42:27 <nitzmahone> ?
15:42:28 <bcoca> the diff is that for once, you control the emitter
15:42:39 <jtanner> nitzmahone: if we write the tool, we can shape the output
15:42:48 <abadger1999> nitzmahone: although... if we control the code for the cli process some of the parsing problems go away...
15:42:52 <jimi|ansible> nitzmahone: it's not really any different than using an ssh connection via the API today
15:42:53 <jtanner> just like we shape the outputs of modules
15:42:58 <nitzmahone> Yeah, but you said "an ssh replacement with paramiko"- that doesn't sound like a JSON emitter
15:43:07 <jtanner> could be
15:43:13 <bcoca> does not have to be, but it can
15:43:20 <abadger1999> nitzmahone: we'd problems on the order of module stdout parsing rather than on the order of bin/ssh output parsing
15:43:25 <nitzmahone> So we're basically writing a new module API over stdin/stdout
15:43:26 <jtanner> it would be paired with a new connection plugin
15:43:39 <bcoca> nitzmahone: welcome to unix
15:43:45 <jtanner> -c perssh
15:44:42 <jimi|ansible> so, i think in order, we should try a background process first, and if that doesn't work the CLI option second
15:44:56 <bcoca> so internal bg vs external bg
15:44:59 <nitzmahone> At least for WinRM, we'd still have to have the ability to run CP-specific code in the controller/connectionmgr to ensure we don't keep too many things open for the same host
15:45:00 <jimi|ansible> and if neither of those work, explore creating a ConnectionManager
15:45:04 <bcoca> what do we do in case of ssh?
15:45:24 <alikins> external helper doesn't necessarily require talking to stdin/stdout, other ipc is an option
15:45:29 <bcoca> do we allow a toggle to use 'external persistence' vs internal?
15:45:32 <jimi|ansible> nitzmahone: yes we would, we're going to have to do that anyway no matter what option we do
15:45:42 <bcoca> alikins: i would prefer stdout than python ipc
15:45:47 <jimi|ansible> there's going to have to be some limit set on the # of persistent connections allowed
15:45:47 <abadger1999> if it were an external process, we wouldn't have to modify the ssh connection plugin at all.
15:46:00 <jimi|ansible> generally for SSH, that's managed on the client side
15:46:04 <bcoca> abadger1999: that is why that option appeals soo much
15:46:19 <abadger1999> we'd just be plugging in subprocess calls to the external process inside of individual conenction plugins.
15:46:43 <bcoca> just like we do now for ssh
15:46:56 <nitzmahone> So you'd basically have a per-CP "connection broker/cache" thing that lives in the controller- the impl could be whatever makes sense for that CP
15:47:07 <bcoca> its not best/most performant, but it is least invasive
15:47:08 <nitzmahone> So for ssh, use what we have
15:47:16 <alikins> stdin/stdout to helper means multiplexed comms to helper
15:47:25 <nitzmahone> For WinRM, manage child processes (or threads)
15:47:48 <nitzmahone> alikins: as in "a Good Thing" or "a Bad Thing"?
15:47:55 <alikins> bad
15:48:09 <abadger1999> alikins: note -- there's two levels here...
15:48:15 <abadger1999> the connection plugin invokes one thing.
15:48:19 <bcoca> alikins: that depends a lot on how you design the helper
15:48:37 <abadger1999> and communicates back and forth over stdout
15:49:12 <bcoca> if designed like ssh, helper can communicate with existing process (starting it if needed)
15:49:12 <abadger1999> but that thing also needs to setup the thing managing the peristence... that can use some other form of IPC.
15:49:23 <bcoca> then no need to multiplex
15:49:27 <abadger1999> <nod>
15:49:55 <bcoca> a) we all agree we need a 'connection manager' (internal or in external tool)
15:50:11 <bcoca> ^ so pool size, expiration and keepalive will all be dealt with in there
15:51:16 <bcoca> the question now is 'how do we interact with it'?
15:51:19 <nitzmahone> Keepalive alone makes me think it should probably be its own process- you're going to potentially have a lot of timer contention there
15:51:56 <bcoca> nitzmahone: not really, keepalive is timed, most contention will come from trying to lock a connection for use
15:52:07 <nitzmahone> Not in Winrm
15:52:13 <bcoca> ^ think db pooling, this is very close to that
15:52:22 <jimi|ansible> if you have everything talking over a queue, you've already got the synchronization you need
15:52:37 <nitzmahone> So long as nobody starves
15:52:39 <bcoca> jimi|ansible: that would be a point in favor for internal implementation
15:52:46 <abadger1999> and the queue doesn't fill up
15:53:04 <bcoca> resource starvation will always be an issue, CM needs to deal with that
15:53:41 <jimi|ansible> those are issues that will arise no matter what solution we go with
15:53:48 <nitzmahone> Connection selection/creation would have to be a per-CP "key" consisting of whatever unique values are necessary for that CP (user/host/env/become state/random), which also implies that each CP needs to register its pool-key vars.
15:54:28 <nitzmahone> (which could end up changing our direction for the psuedo-connection-var fix)
15:54:38 <bcoca> depends, some of that can be 'reset' in the connection
15:54:46 <alikins> should connections (eventually) be shared across 'ansible-*' invocations?  parallel invocations?
15:54:48 <bcoca> loginuser/host seems to be the most basic part
15:54:50 <nitzmahone> For the connection types you know about...
15:55:03 <jimi|ansible> alikins: that's a pro for having an external CLI option
15:55:06 <nitzmahone> WinRM env *should* be handled at the CP level
15:55:07 <jimi|ansible> with that they could be
15:55:09 <bcoca> alikins: possibly, but that is an optimization that might make more sense in Tower
15:55:23 <nitzmahone> I hacked it to work like the other stuff for now, but it's *very* limited because of that
15:55:44 <nitzmahone> (you specify the remote env when you start the shell)
15:55:54 <bcoca> nitzmahone: can you restart a shell?
15:55:58 <nitzmahone> No
15:56:14 <bcoca> so you need new connection every time you want new shell?
15:56:22 <abadger1999> ugh.
15:56:27 <bcoca> ^ that might be big change from how we work now, tasks won't be independant anymore
15:56:31 * abadger1999 tries to figure out how to deal with that...
15:56:47 <bcoca> nitzmahone: almost makes the case to avoid persistence in winrm
15:56:56 <nitzmahone> We don't *have* to do it that way- it's just more efficient if we do. What we have now works OK
15:56:56 <abadger1999> yeah... that seems like a CM can't deal with that.
15:57:33 <jimi|ansible> nitzmahone: is there a way to create a winrm connection to something without a windows host involved?
15:57:43 <jimi|ansible> i'd like to start testing some ideas later
15:57:44 <nitzmahone> not sure I follow
15:57:47 <abadger1999> which makes hte portion of jtanner's idea where the persistence and pooling is handled by something called from the connection plugin rather than something calling the connection plugin seem better.
15:57:56 <jimi|ansible> can i create a connection object without actually connecting to a host?
15:58:03 <jimi|ansible> i want to see if i can pass it around queues at the least
15:58:27 <nitzmahone> IIRC we don't actually connect until you call CP.connect(), if that's what you mean.
15:58:33 * nitzmahone looks
15:58:44 <bcoca> afaik, connection gets created after task/host info is resolved, need host info to populate connection
15:58:45 <jimi|ansible> although i guess if i want to tell if it really survived without being able to use it on the other side of the queue
15:58:55 <jimi|ansible> bcoca: yes that's what i said earlier
15:59:05 <jimi|ansible> that's why having a ConnectionManager class is tricky
15:59:29 <bcoca> it is, that is why i think the external options are good (either bin/helper or tower)
15:59:56 <jimi|ansible> ok, so our BJ call with privateip is about to begin, do we want to accept the 3 options i said earlier and update Peter?
16:00:19 * abadger1999 is leaning more towards the external helper being the number 1 choice.
16:00:32 <jimi|ansible> abadger1999:  you mean the CLI ryansb brought up?
16:00:44 <abadger1999> jimi|ansible: I thought it was jtanner
16:00:51 <jimi|ansible> err yeah jtanner my bad
16:00:57 <abadger1999> yeah.
16:01:00 <jimi|ansible> k
16:01:02 <abadger1999> that's the one
16:01:17 <alikins> a ThingThatIsCapabaleOfRunningAnsibleCommands  (a host/user/shell/module_runtime/env) has a Connection.  both may need pools
16:01:38 <alikins> ie, first is connection+winrm env for ex
16:01:44 <jimi|ansible> (not necessarily ranked just numbered) 1) background managing fork/thread 2) external cli helper 3) ConnectionManager class
16:02:02 <bcoca> there is one issue, the way net modules use connections is very diff than how normal modules do
16:02:18 <jimi|ansible> i don't really want a single process that's running doing all the work of sending out commands
16:02:19 <bcoca> they work more like cloud/api modules
16:02:23 <jimi|ansible> that will serialize things too much
16:03:13 <jimi|ansible> but something that does CP like ssh does (independent, may send something through a pre-existing connection) is fine
16:03:19 <thaumos> can someone list out the 3 options we came up with so it’s easier to parse in notes?
16:03:27 <jimi|ansible> ^ thaumos
16:03:39 <nitzmahone> jimi just did about 5 messages up
16:03:58 <abadger1999> Okay, we're about to start talking with privateip so time to end this meeting.
16:04:02 <bcoca> jimi|ansible: not sure that will work for peter, his modules need the 'serialized version' ... but that might jsut require their own connection plugin and not use the standard ones
16:04:05 <thaumos> hmm, okay.  apologies my scrollback is all messed up then
16:04:23 <abadger1999> We can post some followup to the agenda ticket, though.
16:04:31 <jimi|ansible> bcoca: i don't think that's a problem, i don't know why he'd need a serialized version, i mean serialized across hosts, not tasks
16:04:41 <nitzmahone> agreed
16:04:43 <jimi|ansible> nothing should require something serialized across hsots
16:04:53 <jimi|ansible> otherwise they should be doing `serial: 1` :)
16:04:55 <bcoca> ah, no he needs across tasks
16:05:05 <bcoca> not hosts
16:05:49 <jimi|ansible> #endmeeting