00:02:11  * dan3361quit (Quit: Leaving.)
00:23:20  <rphillips>kostco: why move all the stuff around?
00:23:46  <rphillips>like, function HostInfoStdoutSubProc:run(callback) was already running isRestrictedPlatform
00:24:26  <kostco>hmm it didnt work for me for some reason
00:24:36  <kostco>what you said, i thought so as well
00:24:51  <kostco>but i can move that back and give it a shot, which i was just about to do
00:25:08  <kostco>but uh i made more changes, experimenting with making it a more functional style, looks like it reduces code
00:25:26  <kostco>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/commit/5689eb554a5ac13dd01cf1a4df3963cde799e3da
00:25:58  <rphillips>you still need the initialize() function in lua
00:26:50  <kostco>hmm it runs without it
00:27:01  <kostco>albeit im using the hostinfo runner dunno if that makes a difference
00:28:16  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/5689eb554a5ac13dd01cf1a4df3963cde799e3da/hostinfo/autoupdates.lua#L27-L42
00:28:22  <rphillips>this section of code is placed in the constructor
00:28:48  <rphillips>you need to look at the buildbots as well
00:29:01  <kostco>the buildbots?
00:29:12  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/pull/828
00:29:19  <rphillips>'Some checks were not successful'
00:29:34  <rphillips>you can click through to the builds
00:29:44  <rphillips>https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/74334573#L985
00:29:47  <kostco>oh yeah
00:30:07  <kostco>thats cos it breaks the other checks since they rely on things ive removed, whichll get fixed when i refactor those checks
00:30:43  <kostco>so over there
00:30:43  <kostco>[string "bundle:/hostinfo/iptables.lua"]:22: attempt to index local 'MetricsHandler' (a nil value)
00:32:41  <rphillips>so, this is a ported module: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/a3e1991263fab3b9434500126f9073b3a4f81aa8/hostinfo/ip4routes.lua
00:33:25  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/a3e1991263fab3b9434500126f9073b3a4f81aa8/hostinfo/autoupdates.lua
00:33:27  <kostco>yea but i changed stuff, using the misc.streamingSpawn function instead of the hostinfosubproc bound to self, extended from hostinfo
00:33:35  <rphillips>shouldn't the autoupdates.lua file look like it?
00:35:24  <rphillips>so. parameters to functions should not have side effects
00:36:52  <rphillips>i don't think there is a need for streamingSpawn
00:40:14  <kostco>https://gist.github.com/kaustavha/d7690571b9e59e5498be
00:40:39  <kostco>so thats what ip4routes would look like with a function acting as streaming spawn instead of using the handler and hostinfosubproc
00:41:42  <kostco>the thing is, i need to/want to call the final callback() and abort if the sigar vendor doesnt match up
00:43:43  <kostco>also the metric handler is only ever used with the hostinfosubproc, so either way i think we should merge them somehow so the person writing hostinfo checks doesnt need to initialize it, they can just pass in a function that they want called per line
00:49:40  <rphillips>https://gist.github.com/rphillips/8e5ba84263d58527f636
00:49:44  <rphillips>this is what I was sorta thinking
00:51:39  <rphillips>we could just pass in the class
00:52:13  <rphillips>https://gist.github.com/rphillips/8e5ba84263d58527f636#file-gistfile1-txt-L57
00:52:34  <kostco>so pass inside hostinfostdoutsubproc?
00:52:47  <kostco>if not command return end sort of a deal?
00:53:01  <rphillips>i don't get the use case
00:53:31  <kostco>so if for whatever reason sigar returns a vendor name that isnt recognized
00:53:45  <kostco>e.g. someone trying to run this on a custom arch distro running server
00:53:59  <kostco>arch as in arch linux
00:54:08  <rphillips>https://gist.github.com/rphillips/8e5ba84263d58527f636#file-gistfile1-txt-L53
00:54:12  <rphillips>change this to an else
00:54:18  <rphillips>and it'll just error out on other platforms
00:54:46  <rphillips>we could add one more flag that is like 'enabled'
00:54:56  <rphillips>and check for it on the :run()
00:55:07  <kostco>but can we error intelligently and return something like self._error = "linux distro unsupported"
00:55:09  <rphillips>or a :disable() function
00:55:15  <kostco>hmmm ok
00:55:36  <kostco>yea an enabled flag makes sense, and sounds simple
00:55:43  <rphillips>else self:disable('plugin not supported due to vendor')
00:55:49  <kostco>hmm
00:56:03  * dan336joined
00:56:24  <kostco>so self:disable would be declared in base.lua and would basically set self._error and return callback()?
00:56:42  <rphillips>it would just set the self._error
00:58:08  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/a3e1991263fab3b9434500126f9073b3a4f81aa8/hostinfo/base.lua#L96
00:58:13  <rphillips>we can short circuit it right here
00:58:31  <rphillips>if self._error then callback() else self._execute(callback) end
00:58:54  <kostco>ah alright
01:03:31  * dan336quit (Quit: Leaving.)
01:05:13  <rphillips>kostco: we could assume
01:05:25  <rphillips>if command is nil then the hostinfo is diabled
01:05:27  <rphillips>disabled
01:06:02  <kostco>hmm so we have teh self error set while looking at vendor
01:06:18  <kostco>so just emit the callback
01:06:50  <rphillips>https://gist.github.com/rphillips/8e5ba84263d58527f636#file-gistfile1-txt-L48-L55
01:07:07  <rphillips>so, command is nil
01:07:44  <rphillips>if command is nil, then on that same line 96 in base.lua
01:08:11  <rphillips>have a static constant saying it is disabled
01:08:26  <rphillips>just like on 93
01:08:42  <rphillips>could be the exact same error message
01:09:08  <kostco>hmm but we're not really saying much, its sort of a generic message
01:09:15  <kostco>which i feel down the road might confuse someone
01:09:30  <kostco>like hey why do i get this hostinfo is disabled on ubuntu 20.00
01:09:48  <kostco>well turns out sigar doesnt work, but theyd prolly debug it faster if it said doesnt work on your linux distro
01:10:51  <rphillips>sure... we can add the vendor name
01:11:01  <rphillips>os name as well
01:11:02  <rphillips>etc
01:24:25  * hdmsquit (Quit: hdms)
02:04:38  <kostco>rphillips: thoughts on this:
02:04:38  <kostco>https://gist.github.com/kaustavha/d747a39e616b7be96404
02:05:07  <kostco>its the most succint one ive been able to make, mixes functional and oop a lot though, so mainly all i did was move the handler into the hostinfosubproc class
02:05:12  <kostco>since thats the only place we use the handler
02:05:47  <kostco>therefore when writing hostinfo checks the writer doesnt need to worry about instantiating the handler, just what they want to do with each line, which is the main non repetetive part
02:22:53  <kostco>k ill be back tomorrow
02:28:23  <creationix>kostco: I can look at in the morning when I have more brain left
02:31:34  <rphillips>creationix: https://twitter.com/jedisct1/status/628986328080908288
02:31:40  <rphillips>creationix: pcre vulnerability
02:31:50  <creationix>thanks
02:32:28  <creationix>I need to learn some advanced Heap Fengshui techniques.
02:32:35  <rphillips>kostco: i don't understand what is wrong with the template I wrote
02:33:09  <rphillips>mixing functional and oop is probably not the cleanest
02:33:57  <creationix>functional all the way! ;)
02:34:06  <creationix>but I digress..
02:34:27  <rphillips>+1 to functional
02:37:18  <creationix>I love local variables much more than table properties in lua.
02:37:36  <creationix>they are simpler, explicit, statically checked by the linter and easier on the VM
02:51:14  <rphillips>kostco: part of the problem is that our inheritance model is single inheritance
02:51:54  * hdmsjoined
02:51:59  <rphillips>in C++ we could extend the HostInfo class to be inherited from a Transform as well
02:52:18  <rphillips>and then pipe to self
03:00:09  <daurnimator>you can do multiple inheritance in lua...
03:00:27  <daurnimator>just you probably rightfully chose not to
03:04:15  <rphillips>true
03:04:41  <rphillips>we modeled the inheritence after nodejs, which was single
03:04:49  <rphillips>nodejs/javascript
03:43:57  <creationix>I like rust traits
05:14:13  * SkyRocknRoll_quit (Ping timeout: 264 seconds)
06:02:30  * hdmsquit (Quit: hdms)
06:20:28  * SkyRocknRolljoined
08:39:19  * SkyRocknRollquit (Read error: No route to host)
08:39:52  * SkyRocknRolljoined
08:59:12  * SkyRocknRollquit (Read error: No route to host)
08:59:43  * SkyRocknRolljoined
09:08:04  * piernovquit (Ping timeout: 250 seconds)
09:08:16  * piernovjoined
11:08:39  * SkyRocknRollquit (Ping timeout: 260 seconds)
11:20:40  * SkyRocknRolljoined
12:22:02  * hdmsjoined
13:17:24  * dan336joined
13:32:32  * dan336quit (Quit: Leaving.)
13:33:24  <rphillips>good morning
13:45:05  * SkyRocknRollquit (Remote host closed the connection)
13:51:24  <creationix>rphillips: morning
13:51:42  <creationix>I've been thinking about the pcre CVE, I doubt we are actually vunerable
13:52:38  <creationix>Since it's a heap Feng Shui attack, the limited size of our strings and the fact that they must be valid utf8 seriously limits what can be done
13:55:09  <rphillips>gotcha
13:56:20  <creationix>still, looking at the actual report, it's not hard to overflow the heap, I could be wrong if there is another vector where they can insert large binary strings in memory
13:56:45  <creationix>but pretty much all the user-settable inputs to the agent are short utf8 strings right?
13:57:38  <creationix>the fix is scheduled for September in v8.38. So by the time we go live with the new feature, it should be fine
14:18:34  <creationix>rphillips: have you ever used mdns to discover services on the local network?
14:18:41  <creationix>I mean implemented a server/client pair
14:19:37  <rphillips>i had a pet project once
14:20:06  <rphillips>most production networks have multicast turned off
14:20:22  <rphillips>home network. works just fine
14:24:42  <creationix>my use case is a workshop for kids
14:25:04  <creationix>so at home, mdns might work, but not likely at some event?
14:25:21  <rphillips>Correct. Not likely
14:25:40  <creationix>I suppose this is why most systems these days use some known public internet server to help find stuff
14:26:34  <creationix>public dns -> public server -> local master
14:26:59  <creationix>(assuming the local master also told the public server it’s local address and the querying client also told it the internal address)
14:27:22  <rphillips>You could setup a dynamic
14:27:40  <rphillips>Dns with bind with a restful service
14:27:51  <creationix>internal dns?
14:28:12  <creationix>my linux boxes can find other linux boxes by hostname on my home lan
14:28:17  <creationix>the router is dd-wrt
14:28:26  <creationix>but my mac’s can’t find them by hostname
14:28:47  * dan336joined
14:29:04  <rphillips>You would register mydns.org and set the name server to your cloud server then write your client to register their internal ip to your service
14:29:32  <creationix>oh interesting, use ddns, but publish internal IPs
14:29:58  <rphillips>right... you could use a dynamic provider, or write your own pretty easily
14:30:09  <rphillips>just give it a really low ttl
14:30:12  <creationix>the problem is I have multiple networks
14:30:27  <creationix>I could be at home, at someone else’s house, or on the road using a cell phone hotspot
14:30:51  <creationix>I want to be able to just turn on the master and slaves, connect them to the network and they magically find eachother
14:31:20  <creationix>and I might have multiple masters, one running at home on a rPI, one as a mobile app on my phone and one as a chrome app
14:31:38  <rphillips>ah, you could definetly abuse https://coreos.com/os/docs/latest/cluster-discovery.html
14:31:39  <creationix>the really hard part is some of the clients are web pages
14:32:04  <creationix>but I might just need the master to display it’s local IP somehow and enter that manually into the web clients
14:32:47  <creationix>(publicly hosted, but work offline with appcache)
14:32:56  <rphillips>you could host your own etcd discovery service and not expire tokens
14:33:26  <creationix>but how would i find that service?
14:33:57  <creationix>the thing I’m making is essentially a discovery service, but it needs to work when there is no internet, but is local lan
14:34:10  <rphillips>ah not internet
14:34:14  <rphillips>missed that requirement
14:34:16  <rphillips>no*
14:34:50  <rphillips>if you are connected to the same access point, a broadcast should work
14:34:55  <rphillips>which is basically mdns
14:35:45  <creationix>I guess I could try mdns first and fall back to manual
14:36:02  <creationix>I just don’t have manual on all the clients
14:36:25  <creationix>many are headless nodes (microcontrollers with wifi client)
14:38:24  <creationix>rphillips: thanks for the feedback, it’s a hard problem I’ve been working on for years
14:45:36  <rphillips>yeah, not easy
14:49:53  <rphillips>i always thought the quake3 server discovery was good http://caia.swin.edu.au/reports/070730A/CAIA-TR-070730A.pdf
14:50:44  <rphillips>doesn't solve the issue with server0
14:52:38  <creationix>yep, that works well when you have internet
14:52:47  <creationix>maybe there isn’t one solution for every case
14:52:59  <creationix>but in most cases I should have either internet or mdns right?
14:54:14  <creationix>I can have masters register with a cloud server publishing their internal IP and subnet
14:54:29  <creationix>when a client queries, return all masters with the same subnet
14:54:49  <creationix>though I suppose is the master and client are on the same nat, they will have the same public IP for even faster matching
14:54:52  <creationix>*if
14:54:55  * travis-cijoined
14:54:56  <travis-ci>luvit/luvi#713 (master - babc802 : Tim Caswell): The build passed.
14:54:56  <travis-ci>Change view : https://github.com/luvit/luvi/compare/e59881b0020c...babc8029afee
14:54:56  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/74419642
14:54:56  * travis-cipart
15:02:36  <creationix>wohoo, we have lpeg in luvi-regular
15:02:50  <creationix>I’ve always loved lpeg, but never actually used it much
15:12:03  <creationix>well, that was pretty easy to add :) https://github.com/creationix/virgo-proto/commit/a12ad887f84f73a91d4c9b87e417ef92b3024f34
15:13:51  <creationix>rphillips: rje: when one of you have a chance, I’d like feedback on the interface to my TCP check. See what I’m missing or what would need changing
15:14:15  <rphillips>checking
15:15:52  <creationix>I tried to shape the input and output like somewhat like the noits xml files
15:16:38  <creationix>you can see the input shape at https://github.com/creationix/virgo-proto/blob/master/checks/index.lua#L28-L36 and output at https://github.com/creationix/virgo-proto/blob/master/checks/tcp.lua#L117-L127
15:17:32  <creationix>the goal is to implement each type as a black-box with a well defined external interface. Then I can use coroutines and functional style internally and externally it can interface with the existing agent style
15:18:22  <creationix>actually, if we document the interfaces to all these check types with desired behavior that would help a lot.
15:18:52  <creationix>I attempted to doc it here at https://github.com/creationix/virgo-proto/blob/master/checks/tcp.lua#L20-L50 for example
15:22:09  <rphillips>i think we will need an 'id'
15:22:12  <rphillips>for the check
15:23:45  <rphillips>we will need to support ipv6 as well
15:24:41  <rphillips>the noits allow for selecting ipv4, ipv6, or ipv4/ipv6
15:24:55  <rphillips>we might want to wrap that getaddrinfo so we can support that
15:28:58  <creationix>so ipv6 yes/no as an input flag?
15:29:15  <creationix>and the ID would just be passed through right?
15:30:33  <rphillips>well. we support ipv4 only
15:30:35  <rphillips>ipv6 only
15:30:53  <rphillips>or 'any', ipv4 + ipv6... whichever getaddrinfo return
15:31:02  <creationix>would that go on the generic attributes along with host or in the config along with port?
15:31:11  <rphillips>yes, close to the 'target'
15:31:36  <creationix>ok, so three state (ipv4-only, ipv6-only, both)?
15:33:18  <rphillips>correct
15:34:23  <rphillips>something we should think about is dns usage
15:34:33  <rphillips>the noits run a caching dns server on them
15:34:49  <creationix>heh, you can’t use libuv’s dns to look up localhost
15:34:57  <creationix>luvit’s is a little better I think
15:35:20  <creationix>we could cache dns lookups in ram pretty easily
15:35:41  <creationix>with short lifetimes
15:35:47  <rphillips>yeah, noit does that as well... it is brittle
15:36:00  <rphillips>ours could be better
15:37:03  <rphillips>http://docs.rackspace.com/cm/api/v1.0/cm-devguide/content/service-checks.html
15:37:07  <rphillips>attributes on the check
15:37:15  <rphillips>'disabled' is an option
15:43:05  * creationixquit (Quit: ZNC - http://znc.in)
15:43:28  * creationixjoined
15:44:04  <creationix>alright, irc is back
15:52:54  <creationix>I think I know what happened. I was using my server’s ssh service to test the check banner
15:53:08  <creationix>and got blacklisted for too many failed ssh connections
15:54:18  <rphillips>hah!
15:54:21  <rphillips>that would do it
15:57:55  * SkyRocknRolljoined
16:01:25  <creationix>I should use http for testing
16:20:08  <creationix>alright, now I report partial data on failure
16:20:30  <creationix>so if there is a timeout while waiting for the body, it will still have dls results, dns time, banner data, etc
16:22:37  <creationix>https://gist.github.com/creationix/0eb3960854d1baf69e41
16:38:20  <creationix>rphillips: will dns resolving be common for all remote checks?
16:38:33  <creationix>since target and dns family are part of the common attributes
16:38:52  <rphillips>yeah, it can be an ip or a fqdn
16:57:09  <rphillips>kostco: so, all side effects should be put into the callback
16:57:19  <rphillips>typically, an error is passed first
16:57:28  <rphillips>callback(err, param1, param2, etc)
17:01:37  <kostco>rphillips: my issue is with declaring the metric handler class in the checks is that its repetetive, only, and all of the hostinfo checks that rely on hostinfostdoutsubproc need it, so why not just tie it together and then you just need to worry about the hostinfostdoutsubproc class
17:02:28  <kostco>rphillips: the thing is we want to check the data as it streams, lines coming in need to be checked, so a callback wont work, whats wrong with just reading the lines and modifying state and handling any modifications to said state in the final cb?
17:03:14  <rphillips>it isn't all that reusable
17:03:21  <kostco>rphillips: so the casterfunc in readcast basically does that, draws data from the lines coming in
17:03:53  <kostco>what isnt the metric handler or the data being read by a function sent in via the params
17:05:20  <rphillips>have a code sample?
17:06:14  <kostco>so yea this is with the metric handler merged into the hostinfosubproc class, so it abstracts away the class declaration and just lets the check writer write logic to handle the lines streaming in
17:06:15  <kostco>https://gist.github.com/kaustavha/d747a39e616b7be96404
17:06:51  <kostco>and the readcast function here
17:06:51  <kostco>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/c3cce11157581b60f67c6f96a4af6caef5e35fb2/hostinfo/misc.lua
17:07:06  <rphillips>it's a lot of logic to have in a constructor
17:07:11  <kostco>casterfunc is called once per line, removes a lot of boilerplate for places it needs to be used
17:07:13  <rphillips>it's not testable either
17:07:36  <kostco>couldnt we just write a test that runs the hostinfo checks and returns the data they return?
17:07:47  <kostco>why test the hostinfosubproc when we can directly check wehre its being used
17:08:34  <rphillips>ideally there would be unit tests for each of these hostinfos
17:08:40  <rphillips>with mockups of the files
17:09:09  <rphillips>should not have to rely on the operating system for tests
17:09:16  <kostco>yea we can test that with the hostinfo subproc handling the abstraction for handling streams
17:09:37  <kostco>i do agree that its a lot of logic in a constructer and could prolly be rewritten better
17:09:54  <kostco>but i also feel that initializing the handlers everywhere we use the hostinfosubproc is kinda repettetive
17:10:03  <rphillips>function Info:_handleLine(line)
17:10:17  <rphillips>we could do that
17:10:27  <kostco>sure yea!
17:12:30  <rphillips>problem is, I feel that is not very clean
17:12:49  <rphillips>if it's a separate class we can add a unit test to read a mock file
17:12:59  <rphillips>and :pipe() it into the parser
17:13:04  <rphillips>aka, handler
17:13:21  <rphillips>and compare the results of the parse
17:13:29  <kostco>hmm
17:13:46  <rphillips>so the unit test would be
17:13:49  <kostco>why not have a declaration for the basic hostinfosubproc, and the metric handler in base
17:13:53  <kostco>we can write the unit tests that way
17:14:07  <kostco>but then we can use a version of it with the two classes merged in which we use in the hostinfo checks
17:15:23  <kostco>merged in as in something like
17:15:23  <kostco>exports.hostinfo = hostinfo
17:15:23  <kostco>exports.hostinfosubproc = 'merged class here'
17:15:23  <kostco>exports.hostinfostdoutsubproc = normal hostinfo subproc
17:15:23  <kostco>exports.metricshandler = metricshandler
17:15:23  <kostco>The last two arent actually used in the hostinfo checks
17:15:49  <rphillips>we support single inheritance
17:16:22  <kostco>ah but it wont be inhertence where we merge, itll be sort of similiar to what is happening right now
17:16:51  <rphillips>pr it up, and we can review it
17:16:52  <kostco>a class using another predeclared method on the metrichandler
17:16:54  <kostco>ye
17:17:07  <kostco>lemme see if i cant clean up the code in the gist i posted
17:20:19  * SkyRocknRollquit (Remote host closed the connection)
18:01:25  <kostco>rphillips: creationix https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b
18:20:07  * [zzz]quit (Read error: Connection reset by peer)
18:20:55  <kostco>couple things, i went with the detect self._error bit instead of the self.command nil check here
18:20:55  <kostco>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/commit/afb2bdf5b22d694660158c981633cccb5d25c22c
18:20:55  <kostco>since self.command being nil could mean many things but the test writer can specify an error to be set when initializiation fails/detects something is off.
18:21:21  <kostco>will need to apply the changes from here
18:21:21  <kostco>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/commit/c2fc85abe92bd8ab5234feb07c798a500b60757c
18:21:24  <kostco>to my gist
18:23:07  <kostco>also rphillips do you think itd make sense to have a hostinfo:concurrency function thats set in base and returns the concusrrency number? since right now we just have 5 in a lot of places where we do things with async
18:29:39  <creationix>kostco: sorry, I don’t quite understand the questions
18:29:55  <kostco>creationix: thoughts on the code in the gist
18:30:12  <kostco>im working on refactoring the agent
18:36:50  <creationix>right, I don’t know the existing object model enough to make intellegent comment
18:37:02  <kostco>ah kk fair enough
18:42:08  <rphillips>the initialize function should not have a callback function in it
18:42:14  <rphillips>https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b#file-autoup-lua-L51
18:44:38  <kostco>gotcha gimme one se
18:44:39  <kostco>x
18:44:41  <kostco>c
18:58:22  <kostco>changed it
18:58:24  <kostco>rphillips: https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b
19:18:32  <rphillips>you need to try it out
19:18:38  <rphillips>does it work?
19:21:19  <kostco>rphillips: yes
19:21:38  <kostco>rphillips: i test everything on a remote box
19:23:07  <rphillips>https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b#file-base-lua-L109
19:23:14  <rphillips>this is transforming the base class
19:23:22  <rphillips>transforming is the wrong word
19:23:24  <rphillips>modifying
19:23:42  <rphillips>i don't think this is the right approach
19:24:04  <kostco>rphillips: hmm indeed, i wonder if i can instantiate it first then modify it
19:24:08  <rphillips>I really don't like the _handleLines routine
19:24:34  <kostco>which part of it? why not?
19:25:02  <kostco>im not too picky on how its done, i just feel instantiating the handler when itll only ever be used via the hostinfostdoutsubproc is repetetive
19:25:04  <rphillips>we lose the ability to test it with a stream
19:25:49  <rphillips>it might be repetitive, but it's clear what it's doing
19:30:37  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/ba55e2ee8d7558317869913eef211178016f84ee/hostinfo/packages.lua
19:30:45  <rphillips>i don't know how we could get this much cleaner
19:36:23  <kostco>i think we could actually by not making the test writer worry about the handler being extended and then setting the _transform function
19:36:32  <kostco>easier to understand as a built in handlelines function
19:36:48  <kostco>we can have a version we use with the self:bindmetrichandler()
19:36:58  <kostco>and a testable version without the self:bindmetrichandler()
19:37:22  <kostco>https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b
19:44:41  <kostco>https://gist.github.com/kaustavha/5056b6487125bbdde56d
19:52:15  <kostco>rphillips: https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b
19:52:29  <kostco>updates it, figured we can test it with streams that way if we set a self._test = true
20:22:01  * travis-cijoined
20:22:02  <travis-ci>luvit/luvit#2452 (master - e63e83b : Tim Caswell): The build passed.
20:22:02  <travis-ci>Change view : https://github.com/luvit/luvit/compare/9bea919e0298...e63e83b90991
20:22:02  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/74471467
20:22:02  * travis-cipart
20:33:28  <creationix>rphillips: I fixed luvit/tap to not crash on errors in callbacks again
20:33:39  <rphillips>nice!
20:34:15  <creationix>It used to depend on uv.run throwing an exception which is no longer the case
20:34:28  <creationix>now luv hard exits if you don’t catch exceptions in a event callback
20:34:48  <creationix>but since all callbacks in tap usage are wrapped with expect anyway, I juse wrapped them with pcall and routed the error
20:36:22  <creationix>rphillips: where should this code go in the r-m-a repo? https://github.com/creationix/virgo-proto/tree/master/checks
20:36:34  <creationix>or should I keep developing it here till we’re ready to integrate it?
20:36:48  <rphillips>perhaps a ./poller directory
20:37:01  <rphillips>or if we come up with a better name
20:37:30  <creationix>since all checks are polling, perhaps “remote"
20:43:17  <creationix>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/pull/830/files
20:53:41  <creationix>interesting, luvit’s dns module doesn’t use libuv’s dns functions at all
20:53:56  <creationix>it’s manual dns on top of udp
20:54:24  <rphillips>yeah, libuv doesn't really have any dns functions
20:55:08  <rphillips>getaddrinfo only supports A and AAAA records
20:55:29  <rphillips>nodejs uses c-ares
20:55:56  <creationix>I’m using the libuv one here https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/feat/remote-checks/remote/tcp.lua#L8-L16
20:56:50  <creationix>though they are just thread-pool enabled getnameinfo and getaddrinfo
20:56:57  <rphillips>that is fine for A or AAAA records
20:57:21  <rphillips>use getaddrinfo may become a bottleneck
20:57:25  <rphillips>using*
20:58:36  <kostco>rphillips: take a look at hostinfo/passwd.lua when you get a chance, unsure how to refactor it to match the hostinfosubprocstdout class style, and the autoup gists if you want, should be testable while allowing one to skip declaring the handler class
20:58:47  <creationix>rphillips: right
20:59:08  <creationix>I do wonder how to do a combined ipv6/ipv4 query with luvit’s dns
20:59:15  <creationix>it just has quer4 and query6
20:59:22  <creationix>*query4
21:00:09  <creationix>I suppose I could just call query4 first and then fall-through to query6 if that doesn’t work
21:00:46  <rphillips>creationix: i would use getaddrinfo from libuv
21:00:50  <rphillips>we don't have a function for it
21:01:31  <rphillips>that will allow for the OS to select the best fit
21:02:48  <creationix>got it, I’ll use the luvit library when I get to dns checks that need other types
21:03:19  <rphillips>exactly +1
21:03:45  <rphillips>the getaddrinfo from libuv also allows for hints
21:04:35  <creationix>I like doing things like passing in “https” for port and it gives back 443
21:04:47  <creationix>not sure how useful that information is though, it’s probably a small database
21:04:58  <rphillips>kostco: so adding a _transform using a stream looks like this: https://gist.github.com/rphillips/ff53252b5ea2a8886edd
21:05:06  <rphillips>i'm not buying it... it seems more complicated
21:06:11  <rphillips>creationix: i'm thinking we should hardcode our default ports
21:06:23  <rphillips>for the major port numbers everything should match up
21:06:45  <rphillips>but there will be one of those systems that has a different services database
21:06:59  <creationix>rphillips: what do you mean? The users specify the ports in case of remote checks right?
21:07:25  <rphillips>i think you are saying passing in 'https' into getaddrinfo
21:07:42  <creationix>right, I do that sometimes for fun
21:07:46  <creationix>not sure it’s ever a good idea
21:07:47  <rphillips>:)
21:08:00  <rphillips>that use case, I'm just thinking of a stale services database
21:09:31  <creationix>but since I am passing the value to libuv from the user, they could type in “https” instead of a number and it would work
21:09:43  <creationix>(of course ele would invalidate it long before it got to us)
21:09:54  <rphillips>ah ok
21:21:35  <kostco>gotta go to a docker workshop so brb
21:22:12  <kostco>rphillips: did you get a chance to take a look at
21:22:12  <kostco>https://gist.github.com/kaustavha/7ff3f649ed5a90968b2b
21:22:12  <kostco>Yay/nay? is that what you said seemed more complicated
21:25:50  <kostco>shoulldve prolly waited till maas week before starting the refactoring process
22:35:56  <coderkevin>So, I'm looking into porting Luvit to QNX. Does anyone have a recommendation as to where I should start? Start with libuv first, then go from there?
22:57:29  * dan336quit (Quit: Leaving.)
23:33:10  <creationix>coderkevin: right, libuv and luajit are the hardest parts
23:33:16  <creationix>the rest is fairly portable
23:33:39  <creationix>rphillips: looks like George is doing something with robots https://github.com/libuv/libuv/pull/379
23:33:45  <creationix>I would love a serial primitive in libuv
23:43:14  <rphillips>that is really really cool