00:04:56  * hdmsquit (Quit: hdms)
01:09:12  * kazuponjoined
01:28:01  * joconnorquit (Ping timeout: 256 seconds)
03:06:16  * kazuponquit (Remote host closed the connection)
03:06:44  * kazuponjoined
03:10:48  * kazuponquit (Ping timeout: 245 seconds)
03:32:20  <rphillips>nice
04:23:06  * kazuponjoined
05:16:13  * SkyRocknRolljoined
05:20:04  * SkyRocknRollquit (Read error: No route to host)
05:29:58  * SkyRocknRolljoined
05:29:58  * SkyRocknRollquit (Changing host)
05:29:58  * SkyRocknRolljoined
06:16:28  * SouL_|_joined
06:37:12  * kazuponquit (Remote host closed the connection)
07:20:58  * a_lejoined
07:22:47  * kazuponjoined
07:58:39  * a_lequit (Remote host closed the connection)
08:19:28  * SouL_|_quit (Read error: Connection reset by peer)
08:22:29  * SouL_|_joined
08:34:54  * kazuponquit (Remote host closed the connection)
08:47:01  * a_lejoined
08:50:40  * a_lequit (Read error: Connection reset by peer)
08:51:02  * a_lejoined
09:13:20  * UniOnjoined
09:37:43  * a_lequit (Remote host closed the connection)
09:41:43  * a_lejoined
09:42:56  * a_lequit (Remote host closed the connection)
10:10:04  * kazuponjoined
10:14:50  * kazuponquit (Ping timeout: 265 seconds)
10:47:38  * kazuponjoined
12:11:04  * SouL_|_quit (Ping timeout: 245 seconds)
12:23:36  * hdmsjoined
12:23:36  * hdmsquit (Client Quit)
12:25:56  * kazuponquit (Remote host closed the connection)
12:35:54  * ldub_joined
12:43:51  * a_lejoined
12:48:02  * a_lequit (Ping timeout: 252 seconds)
13:29:13  * gavellanedajoined
13:29:38  <gavellaneda>hello, good morning
13:38:19  * ldub_quit (Ping timeout: 265 seconds)
13:39:52  * ldub_joined
13:40:43  <rphillips>good morning!
13:59:47  * hdmsjoined
14:11:12  <gavellaneda>hello rphillips, how are you? I'm working on some changes in the http module of luvit. As you suggested I will use another branch for the next PRs. For some reason I was getting an a core dump error when making https request with the luvit version 2.0.1, but with the 2.0.5 version it seems to work fine now.
14:11:58  <rphillips>there was some lua-openssl fixes probably within that timeframe
14:14:13  * ldub_quit (Ping timeout: 248 seconds)
14:15:31  <gavellaneda>yes I saw you and tim working on that, nice work by the way
14:16:19  <rphillips>thanks
14:18:12  * ldub_joined
14:26:57  * ldub_1joined
14:28:37  * ldub_quit (Ping timeout: 264 seconds)
14:44:17  * hdmsquit (Quit: hdms)
14:44:35  * hdmsjoined
14:58:45  * kazuponjoined
15:36:24  * kazuponquit (Remote host closed the connection)
15:36:51  * kazuponjoined
15:41:10  * kazuponquit (Ping timeout: 244 seconds)
15:58:06  * kazuponjoined
16:22:36  * ldub_1quit (Ping timeout: 240 seconds)
16:22:54  * ldub_joined
16:29:40  * SkyRocknRollquit (Remote host closed the connection)
16:29:49  * joconnorjoined
16:36:37  * ldub_quit (Ping timeout: 248 seconds)
16:46:42  * SouL_|_joined
17:27:43  * kazuponquit (Remote host closed the connection)
17:38:45  <creationix>rphillips: so I was thinking that the agent doesn’t need full lit client baked in, but a simple content-addressable sync protocol like what’s in lit
17:39:04  <creationix>and it will get the objects from the AEP directly in the same stream as commands
17:49:09  * hdmsquit (Ping timeout: 248 seconds)
17:50:12  * hdmsjoined
17:55:48  <rphillips>that would be slick
17:57:23  <creationix>rphillips: did you see how nice weblit handles tls and websocket’s now? https://github.com/creationix/virgo-proto/blob/f54a968e86da0273ddbec8455e6b10b2719c2bfc/master/main.lua
17:57:27  <creationix>makes me happy
17:57:58  <rphillips>i thought that was sweet
17:58:13  <rphillips>i thought websockets needed a path... that isn't the case?
17:58:22  <rphillips>like /v1/socket
17:58:36  <creationix>they don’t need a path
17:58:43  <creationix>it’s just like any other http request
17:58:47  <rphillips>gotcha
18:01:08  <creationix>I tihnk I’ll merge it into route to make it more obvious how it works
18:01:52  <creationix>then you can route websockets based on url patterns and hostname blobs
18:03:35  <creationix>the headers tell you if it’s a websocket request. Upgrade: websocket, Connection: Upgrade, Sec-Websocket-Protocol: 13, etc..
18:12:51  <rphillips>ah hah
18:17:18  <torque>using routes for websockets doesn't really make sense, does it?
18:17:46  <creationix>torque: sure it does, the same as routes for any request
18:17:57  <torque>I guess you could use it as a method of protocol selection, but it seems a bit confusing to do it that way rather than just using the header
18:18:02  <creationix>rphillips: ok, added a route to make the proxy’s job easier https://github.com/creationix/virgo-proto/blob/d13f37b0e50c8e883f00e690b41f1ddd9cda919f/master/main.lua
18:18:10  <creationix>torque: right, the protocol header is great for that
18:18:20  <creationix>but imagine you have a proxy in front, it needs to treat websocket routes special
18:18:32  <creationix>and you may have multiple resources that all use the same protocl
18:18:46  <torque>you're right
18:21:12  <torque>I haven't really looked at your server library in depth, but I assume the handoff to the websocket handler happens before parsing the route, then?
18:21:40  <creationix>torque: route handling is first in this case
18:22:14  <creationix>it uses the generic route to filter on GET and any path or host the user specified https://github.com/creationix/weblit/blob/master/libs/weblit-websocket.lua#L79-L83
18:23:01  <creationix>then the websocket handler checks for special websocket headers, checks for a custom user filter function and then finishes the handshake (verifying the sec key) before handing control to the websocket app logic
18:24:07  <creationix>the weblit loop that was handling http keepalive will abort it’s loop and let the websocket have full control over the socket https://github.com/creationix/weblit/blob/master/libs/weblit-app.lua#L166-L168 https://github.com/creationix/weblit/blob/master/libs/weblit-websocket.lua#L61-L72
18:25:38  <creationix>unlike node.js, this means that websocket request are handled just like any other request. The 101 response gets picked up by the logging middleware, you could have auth middlewares that did things before the routing handler saw it, etc
18:27:14  <torque>ah right, I'm dumb
18:27:35  <creationix>no, you’re not dumb, it just takes a bit to take it all in
18:27:48  <creationix>I’ve been implementing and designing websocket frameworks for years
18:27:54  <torque>for some reason I was thinking of the same route being used for http and websockets which doesn't make sense
18:28:34  <torque>very good, carry on, well done
18:29:18  <torque>thanks for the explanation, though. It was helpful.
18:29:25  <creationix>you’re welcome
18:32:47  * gavellanedaquit (Ping timeout: 246 seconds)
18:36:28  <creationix>torque: but yes, the same route can be used for normal http and websockets. That’s how https://lit.luvit.io and wss://lit.luvit.io work
18:36:43  <creationix>well, same url, maybe not “route” in the framework sense
18:38:57  <torque>yeah, I was thinking in the framework sense, which also could probably work
18:39:04  <torque>but it would be a very silly thing to do
18:39:45  <creationix>the interface is pretty different between websocket and http. In weblit, websocket is (req, read, write) and normal http is (req, res)
18:39:47  * gavellanedajoined
18:40:46  <torque>makes sense because they're different types of connections
18:40:52  <creationix>yep
18:41:24  <creationix>it’s pretty funny how much I use websockets these days and the client is never a browser
18:41:37  <creationix>I just like the semantics and the practicality
18:41:52  <creationix>wss:// works with most all firewalls
18:42:23  <creationix>it has message framing, a few message types, protocol negotation, custom per-message bits, etc
18:42:58  <creationix>and I like it that a browser client *could* talk to my service if it wanted to. You could totally write a lit client in JS that runs in the browser
18:43:11  <creationix>I’m not sure what it would do with all that lua code, but it could be done
18:44:41  <creationix>maybe a really advanced lit pacakge browser that actually lets you look at the code and even edit or update code
18:45:03  <creationix>you could generate an RSA key pair in the browser and upload the public half to github using oauth
18:45:17  <creationix>then you could authenticate with lit and publish new packages entirely from a browser
18:45:32  <torque>scary thought
18:45:52  <creationix>I worked for a couple years on trying to make chromebooks a first-class development environment
18:45:58  <creationix>I got pretty far, but ran out of money and time
18:46:24  <torque>the world isn't ready to embrace the browser-as-os yet, I feel
18:46:58  <creationix>but with a lua vm implemented in js, you could make a fully capable lit/lua development environment that worked offline and synced with github and lit when online, without the assistance of some other cloud server
18:48:02  <creationix>this vm is pretty good http://moonshinejs.org/
18:49:02  <creationix>the browser is no less a real platform than all the virtualized linux boxes running the web
18:49:20  <creationix>just a different set of primitves than systems people are used to thinking about
18:49:59  <torque>the problem being that javascript is a poorly designed and thought out language
18:50:13  <torque>though it's improving in that regard
18:50:45  <creationix>yep, that’s a technical issue. Having tried my hand at writing a fast lua vm in JS I know what an amazing job moonshine is
18:51:06  <creationix>also is seems asm.js is going cross-platform with even IE starting to support it
18:51:25  <creationix>AOT compilation to native code bypasses all the nasties in JS
18:51:40  <creationix>it’s just the weirdest, ugliest assembly you’ve ever looked at
19:57:13  * kazuponjoined
20:02:13  * kazuponquit (Ping timeout: 264 seconds)
20:32:04  <creationix>rphillips: so in the prototype, the agent knows which machine ID’s it is responsible for, but how does it know those machine’s addresses (for remote poller)?
20:32:19  <creationix>is that local information or provided by the aep along with the commands to run
20:33:18  <creationix>for example, I want to poll lit.luvit.io and am setting up a multi-tenant agent. How do I know the id of lit.luvit.io when configuring?
20:34:01  <creationix>perhaps for remote poller, we don’t hard-code any sites to the agent, but rather let the endpoints assign clients to the agent?
20:34:45  <creationix>instead the agent knows the id of it’s physical location on the network (like a certain data center, for example)
20:35:36  <creationix>then when a new check comes in that needs to be from that data-center, we know which connected poller agents can handle it (as well as how much load we’ve assigned to each)
20:35:51  <rphillips>that is provided by the AEP
20:36:00  <rphillips>i'm finding the doc
20:36:24  <rphillips>http://docs.rackspace.com/cm/api/v1.0/cm-devguide/content/appendix-check-types-remote.html#section-ct-remote.http
20:36:41  <rphillips>welp
20:36:49  <rphillips>that section of the doc didn't have what I was looking for
20:37:21  <creationix>right, it tells it what check to run, but not where to report the data to
20:37:29  * a_lejoined
20:37:33  <rphillips>http://docs.rackspace.com/cm/api/v1.0/cm-devguide/content/service-checks.html
20:37:43  <rphillips>target_hostname
20:37:50  <rphillips>or target_alias
20:38:30  <rphillips>the check has these two fields
20:38:40  <rphillips>the entity has a map of aliases as well
20:38:51  <rphillips>so one of these two attributes are set on the check
20:39:27  <rphillips>i think your thought on letting the endpoints assign clients is the right approach
20:39:28  <creationix>so entityId is the machine/target (aka client)
20:40:00  <rphillips>entityId is the unique key of the entity
20:40:10  <creationix>right, but what is an “entity"?
20:40:13  <rphillips>target_hostname is the fqdn or IP of the machine under test
20:40:28  <rphillips>creationix: vidyo?
20:40:33  <creationix>sure
20:41:00  <rphillips>i'm in your room
20:55:28  <rje>rphillips: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/pull/703
21:03:32  * hdmsquit (Remote host closed the connection)
21:10:18  * hdmsjoined
21:17:16  <rphillips>rje: ready?
21:17:32  <rje>?
21:19:06  <rphillips>oh, is that ready for review?
21:19:17  <rje>yes
21:24:38  <rphillips>rje: something with the linux build failed
21:24:59  <rphillips>hmm. mysql test
21:26:10  <rphillips>rje: perhaps a rebase from luvi-up?
21:28:17  <rphillips>hmm
21:28:22  <rphillips>seems to be up to date
21:31:49  * travis-cijoined
21:31:50  <travis-ci>luvit/luvit#2012 (master - ad4857c : Tim Caswell): The build passed.
21:31:50  <travis-ci>Change view : https://github.com/luvit/luvit/compare/47c0b4be2350...ad4857c1596f
21:31:50  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/59944586
21:31:50  * travis-cipart
21:42:26  <rje>rphillips: hmmm
21:42:34  <rphillips>got a fix
21:42:37  <rphillips>i'll commit
21:46:11  <rphillips>rje: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/commit/94d5e9cd9942f1831817a596b92fcd71c77fbcec
21:46:34  <rphillips>the 'Using config file' log line needed to be done after the check_runner loader
21:46:40  <rphillips>it messed with the plugins
21:46:58  <rphillips>also returned early from the windows service module
21:46:58  * gavellanedaquit (Ping timeout: 244 seconds)
21:47:04  <rphillips>if not on windows
21:48:25  <rje>ah, i see. thanks. since the mysql test is a subprocess check this caused that issue
22:13:16  <rphillips>rje: lgtm
22:13:45  <rphillips>have a great weekend everyone
22:14:33  <rje>rphillips: you too, this time for reals!
22:16:40  * a_lequit (Remote host closed the connection)
22:55:58  * gavellanedajoined
23:05:15  * hdmsquit (Ping timeout: 276 seconds)
23:05:57  * hdmsjoined
23:20:26  * hdmsquit (Quit: hdms)
23:48:21  * hdmsjoined