00:00:08  * ircretaryjoined
00:01:07  * c4miloquit (Remote host closed the connection)
00:01:50  * kscully27joined
00:06:16  * kscully27quit (Read error: No route to host)
00:06:38  * kscully27joined
00:07:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:07:59  * andreypoppquit (Quit: andreypopp)
00:09:57  * joshonthewebquit (Quit: Computer has gone to sleep.)
00:11:15  * mdedetrichquit (Quit: Computer has gone to sleep.)
00:13:36  * kscully27quit (Remote host closed the connection)
00:23:14  * alxquit (Remote host closed the connection)
00:28:50  * Heboquit
00:31:01  * alxjoined
00:33:53  * TooTallNatejoined
00:34:55  * mdedetrichjoined
00:38:12  * Samuel_Roldanjoined
00:43:12  * sandfoxquit (Quit: sandfox)
00:43:27  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:53:40  * kujajoined
01:00:22  * leichtgewichtjoined
01:06:34  * bzoojoined
01:08:28  * bzooquit (Remote host closed the connection)
01:09:04  * bzoojoined
01:13:02  * bzooquit (Ping timeout: 240 seconds)
01:16:18  * i_m_cajoined
01:21:34  * indexzerojoined
01:24:10  * kscully27joined
01:28:43  * indexzeroquit (Ping timeout: 264 seconds)
01:29:43  * kscully27quit (Ping timeout: 260 seconds)
01:35:51  * i_m_caquit (Ping timeout: 245 seconds)
01:41:36  * jcrugzzjoined
01:44:11  * InconceivableBjoined
01:47:19  * mokesjoined
01:52:06  * mokesquit (Ping timeout: 264 seconds)
01:57:44  * paralleljoined
01:59:25  * everettquit (Ping timeout: 250 seconds)
02:03:38  * mdedetrichquit (Quit: Computer has gone to sleep.)
02:08:08  * parallelquit (Remote host closed the connection)
02:08:39  * paralleljoined
02:08:57  * parallelquit (Read error: Connection reset by peer)
02:09:22  * paralleljoined
02:23:03  * InconceivableBquit (Quit: Computer has gone to sleep.)
02:24:58  * parallelquit (Remote host closed the connection)
02:27:42  * mdedetrichjoined
02:31:04  * InconceivableBjoined
02:32:46  * InconceivableBquit (Client Quit)
02:39:37  * thealanwattsriotjoined
02:39:44  * thealanwattsriotquit (Max SendQ exceeded)
02:48:44  * InconceivableBjoined
02:53:32  * mdedetrichquit (Quit: Computer has gone to sleep.)
02:54:13  * mdedetrichjoined
02:56:59  * Samuel_Roldanquit (Quit: Samuel_Roldan)
03:00:59  * daviddiasjoined
03:01:46  * daviddia_joined
03:02:19  * alxquit (Remote host closed the connection)
03:05:38  * daviddiasquit (Ping timeout: 264 seconds)
03:10:34  * thealanwattsriotjoined
03:17:05  * thealanwattsriotquit (Ping timeout: 245 seconds)
03:26:26  * Samuel_Roldanjoined
03:26:59  * mdedetrichquit (Quit: Computer has gone to sleep.)
03:29:01  * mdedetrichjoined
03:35:30  * paralleljoined
03:40:03  * parallelquit (Ping timeout: 256 seconds)
03:47:53  * joshsmithquit (Quit: joshsmith)
03:48:23  * joshsmithjoined
03:50:49  * joshonthewebjoined
04:05:21  * paralleljoined
04:05:56  * parallelquit (Read error: Connection reset by peer)
04:06:29  * paralleljoined
04:06:45  * ipalreadytakenjoined
04:08:53  * tobie_joined
04:12:53  * alxjoined
04:15:14  * parallelquit (Ping timeout: 264 seconds)
04:17:37  * calwebjoined
04:18:06  * alxquit (Ping timeout: 264 seconds)
04:19:11  * daviddia_quit (Remote host closed the connection)
04:19:46  * daviddiasjoined
04:21:33  * daviddia_joined
04:22:43  * mdedetrichquit (Quit: Computer has gone to sleep.)
04:24:15  * daviddiasquit (Ping timeout: 260 seconds)
04:24:25  * mdedetrichjoined
04:24:26  * joshsmithquit (Quit: joshsmith)
04:28:11  * sicularsjoined
04:30:17  * paralleljoined
04:31:55  * parallelquit (Read error: Connection reset by peer)
04:32:03  * parallel_joined
04:33:45  * Fishrock123joined
04:34:53  * paralleljoined
04:34:53  * parallel_quit (Read error: Connection reset by peer)
04:35:52  * Fishrock123quit (Remote host closed the connection)
04:37:15  * chakritjoined
04:37:15  * chakritquit (Changing host)
04:37:15  * chakritjoined
04:38:53  * mokesjoined
04:39:48  * Samuel_Roldanquit (Quit: Samuel_Roldan)
04:40:12  * cronopioquit (Quit: Bye)
04:41:37  * InconceivableBquit (Quit: Computer has gone to sleep.)
04:43:24  * mokesquit (Remote host closed the connection)
04:44:16  * mokesjoined
04:44:30  * alxjoined
04:46:32  * daviddia_quit (Remote host closed the connection)
04:47:00  * daviddiasjoined
04:49:59  * jafarjoined
04:50:35  <jafar>hello
04:51:04  <jafar>Getting an error "No free servers available"
04:51:50  * daviddiasquit (Ping timeout: 264 seconds)
04:52:31  * bzoojoined
04:54:20  * alxquit (Remote host closed the connection)
04:55:41  * JoseBjoined
04:56:23  * parallelquit (Read error: Connection reset by peer)
04:56:55  * paralleljoined
04:56:58  * Victor__joined
04:58:24  * Victor__quit (Client Quit)
04:58:31  * mokesquit (Remote host closed the connection)
04:58:57  * joshonthewebquit (Quit: Textual IRC Client: http://www.textualapp.com/)
05:00:15  * joshonthewebjoined
05:00:38  * Samuel_Roldanjoined
05:01:22  * mokesjoined
05:03:21  * parallelquit (Read error: Connection reset by peer)
05:03:48  * c4milojoined
05:03:56  * paralleljoined
05:07:46  * JoseBquit (Quit: Textual IRC Client: www.textualapp.com)
05:08:07  * tobie__joined
05:08:24  * parallelquit (Read error: Connection reset by peer)
05:08:43  * paralleljoined
05:08:53  * jcrugzzquit (Ping timeout: 268 seconds)
05:09:19  * _yoy_quit (Quit: Leaving...)
05:09:22  * tobie_quit (Ping timeout: 246 seconds)
05:10:42  * c4miloquit (Remote host closed the connection)
05:10:54  * _yoy_joined
05:12:13  * bzooquit (Remote host closed the connection)
05:12:45  * bzoojoined
05:14:29  * mdedetrichquit (Quit: Computer has gone to sleep.)
05:15:45  * _yoy_quit (Client Quit)
05:16:31  * mdedetrichjoined
05:17:17  * _yoy_joined
05:17:31  * bzooquit (Ping timeout: 268 seconds)
05:17:46  * tobie__quit (Read error: Connection reset by peer)
05:17:58  * secobarbitaljoined
05:18:52  * tobie_joined
05:19:16  * mokesquit (Remote host closed the connection)
05:20:20  <secobarbital>getting "No free servers available" :(
05:21:07  <secobarbital>is it possible to not bring down the "old" drone until the new drone is allocated and running?
05:21:19  <secobarbital>that way when you run out of servers our app won't be down
05:23:25  <secobarbital>jitsu deploy seems very risky given the app goes down with possibility of staying down
05:29:49  * parallelquit (Read error: Connection reset by peer)
05:30:03  * paralleljoined
05:32:57  * mokesjoined
05:34:21  * Mordecai_joined
05:34:33  <Mordecai_>o.o
05:34:49  <Mordecai_>Oh hi guys, do you know about the error of no free servers available?
05:35:57  * parallelquit (Remote host closed the connection)
05:40:42  * mokesquit (Remote host closed the connection)
05:45:12  * sreeixjoined
05:47:49  * i_m_cajoined
05:52:52  * Samuel_Roldanquit (Quit: Samuel_Roldan)
05:56:46  * joeybakerquit (Quit: Computer has gone to sleep.)
05:58:21  * ionellajoined
06:03:22  * jafarquit (Quit: Page closed)
06:04:55  * alxjoined
06:08:37  * spolujoined
06:08:43  <calweb>same as the others, getting the 'No Free Servers' available error
06:08:51  <Mordecai_>D:
06:08:56  <Mordecai_>it strikes again!
06:09:34  * alxquit (Ping timeout: 246 seconds)
06:10:09  <calweb>i have my drone back! thanks
06:13:33  * chakritquit (Ping timeout: 276 seconds)
06:26:04  * mdedetrichquit (Quit: Computer has gone to sleep.)
06:27:54  * mdedetrichjoined
06:29:52  * thiaminejoined
06:32:33  * tylerstalderquit (Quit: Computer has gone to sleep.)
06:33:47  * tylerstalderjoined
06:37:11  * Dorphernjoined
06:44:06  * chakritjoined
06:46:30  * paralleljoined
06:48:21  * chakritquit (Ping timeout: 245 seconds)
06:50:42  * parallelquit (Ping timeout: 240 seconds)
06:51:18  * mokesjoined
06:52:40  * Slyquit (Remote host closed the connection)
06:53:53  * mdedetrichquit (Quit: Computer has gone to sleep.)
06:54:32  * Dorphernquit (Quit: Dorphern)
06:54:53  * defunctzombie_zzchanged nick to defunctzombie
06:55:25  * mokesquit (Ping timeout: 245 seconds)
06:56:57  * tonistjoined
06:59:11  * tonistquit (Client Quit)
06:59:19  * Slyjoined
07:04:36  * ipalreadytakenquit (Remote host closed the connection)
07:10:55  * andreypoppjoined
07:16:08  * tylerstalderquit (Quit: Computer has gone to sleep.)
07:19:25  * tonistjoined
07:21:33  * andreypoppquit (Quit: andreypopp)
07:21:59  * mokesjoined
07:24:57  * chakritjoined
07:25:41  * ejeklintjoined
07:27:03  * Tom0101joined
07:27:03  * mokesquit (Remote host closed the connection)
07:28:10  <Tom0101>I'm storing my sessions in my database, which is necessary with a cluster. However with nodejitsu this means that whenever I run my app from a different place than MongoLab's datacenter (e.g. my development PC), each single request takes about 1-2 seconds...
07:28:26  <Tom0101>Is there anything that can be done about this?
07:28:46  <Tom0101>see also https://github.com/kcbanner/connect-mongo/issues/81
07:30:41  * jbprosjoined
07:32:02  * ionellaquit (Remote host closed the connection)
07:34:26  * calwebquit (Quit: Leaving.)
07:36:22  * mdedetrichjoined
07:37:27  * mdedetrichquit (Max SendQ exceeded)
07:38:08  * mdedetrichjoined
07:40:42  * barrynageljoined
07:44:12  <thiamine>hey
07:45:17  * chakritquit (Quit: leaving)
07:47:04  * mokesjoined
07:49:28  * mokesquit (Remote host closed the connection)
07:58:34  * ejeklintquit (Quit: ejeklint)
07:59:00  * defunctzombiechanged nick to defunctzombie_zz
08:10:26  * i_m_caquit (Ping timeout: 245 seconds)
08:10:31  * leichtge_joined
08:12:16  * ejeklintjoined
08:13:53  * leichtgewichtquit (Ping timeout: 268 seconds)
08:14:16  * jbprosquit (Quit: jbpros)
08:15:12  * ipalreadytakenjoined
08:19:35  * ipalreadytakenquit (Ping timeout: 245 seconds)
08:25:32  * jbprosjoined
08:29:18  * ionellajoined
08:29:51  * sicularsquit (Quit: siculars)
08:32:21  * tylerstalderjoined
08:32:50  * tylerstalderquit (Read error: Connection reset by peer)
08:32:59  * tonistquit (Quit: tonist)
08:33:14  * tylerstalderjoined
08:36:44  <BruNeX>heya
08:37:19  <BruNeX>i'm having some problems with deply
08:37:26  <BruNeX>djitsu deploy*
08:38:51  <BruNeX>https://gist.github.com/NeCkEr/6339285
08:42:00  * tylerstalderquit (Quit: Computer has gone to sleep.)
08:42:45  * Mordecai_quit (Quit: Computer has gone to sleep.)
08:43:16  * tonistjoined
08:45:51  <BruNeX>already working thanks
08:47:20  * andreypoppjoined
08:58:11  * julianduquequit (Ping timeout: 260 seconds)
09:00:03  * mokesjoined
09:02:56  * pjbrinckjoined
09:04:42  <pjbrinck>having problems with seeing the log my nodejitsu webops, it says "Streaming logging information" but nothing ever shows, my app is running ok, its been like this for several days, my username is pjbrinck, any help?
09:05:04  * mokesquit (Ping timeout: 268 seconds)
09:07:34  <swaagie>pjbrinck: hey there
09:07:43  <swaagie>which browser are you viewing the logs in?
09:07:57  <swaagie>assuming your using webops
09:08:09  <pjbrinck>swaagie: Im in Google Chrome
09:08:29  <swaagie>hmm, can safely exclude that then, what is the appname?
09:08:30  <pjbrinck>swaagie: yes using webops
09:08:46  <pjbrinck>swaagie: appname is jungle
09:08:53  * defunctzombie_zzchanged nick to defunctzombie
09:09:16  <swaagie>pjbrinck: any errors that pop up in the console of chrome?
09:09:28  <pjbrinck>swaagie: checking
09:10:04  * mdedetrichquit (Quit: Computer has gone to sleep.)
09:10:17  <pjbrinck>swaagie: nope, no errors in chrome
09:10:53  <swaagie>pjbrinck: is there a proper working socket connection visible in the network tab?
09:11:48  * mdedetrichjoined
09:11:49  <pjbrinck>swaagie: auch, U got me there, help me help U plz, where do I see the network tab
09:12:18  <swaagie>pjbrinck: it should be in the console as well, 3rd tab, I'm assuming websocket failures, as alternative you could do a `jitsu logs tail` from the command line inside the project directory that is
09:12:36  <swaagie>it might be that a firewall or such is blocking the websocket
09:13:40  <swaagie>pjbrinck: hmm well
09:13:46  <pjbrinck>swaagie: I have the following tabs under Apps: Snapshots, Logs, and Environment variable, I dont have a network tab
09:13:47  <swaagie>where is stuff logged
09:14:04  <swaagie>pjbrinck: that was in the console, but nvm that, I see the latest logs are from 9:55
09:14:13  <swaagie>or in relative time an hour back
09:14:23  <swaagie>perhaps we should add the latest 10 logs line to webops
09:14:31  <pjbrinck>swaagie: sounds correct
09:14:43  <pjbrinck>swaagie: I have same behavior on Firefox
09:14:45  <swaagie>so it works fine, but yeah not really user friendly
09:15:05  <swaagie>yeah pjbrinck do you got access to jitsu on the command line?
09:15:18  <pjbrinck>swaagie: yes
09:15:23  <pjbrinck>swaagie: what should I try
09:15:29  <swaagie>jitsu logs tail
09:15:39  <swaagie>it does retrieve the latest 10/20 lines
09:16:01  <swaagie>I'm going to improve webops
09:17:36  <pjbrinck>swaagie: it says no logs for jungle in specified time span
09:18:05  <swaagie>hmm thats akward
09:18:24  <swaagie>pjbrinck: could you run it with --debug and gist me the output?
09:18:48  <pjbrinck>swaagie: ok gime a few
09:18:52  * defunctzombiechanged nick to defunctzombie_zz
09:18:53  <pjbrinck>swaagie: ok gime a few mins
09:19:23  * mdedetrichquit (Quit: Computer has gone to sleep.)
09:19:48  <swaagie>pjbrinck: sure no rush, here to stay :)
09:22:18  <pjbrinck>swaagie: seems I was a bit wrong, I did an upgrade of jitsu and now I get a log ... on jitsu
09:22:55  <swaagie>pjbrinck: ah k great
09:23:18  <swaagie>pjbrinck: I'll improve webops so everyone will have a more user friendly experience there as well
09:23:22  * InconceivableBjoined
09:23:24  <pjbrinck>swaagie: bt still, I dont see all I expected
09:23:48  <swaagie>pjbrinck: what's missing?
09:23:56  <pjbrinck>swaagie: I'm running Express.js, which logs response times on all calls, I dont see them here
09:24:55  <pjbrinck>swaagie: but that could be an error on my part, let me investigate a bit more and revert
09:25:37  <swaagie>anything written to stdout/stderr should show in the logs
09:25:55  <pjbrinck>swaagie: exactly
09:26:40  <pjbrinck>swaagie: but all I see is the console log I write on my server start up, I dont see any Express.js statements
09:27:12  <pjbrinck>swaagie: let me run it on localhost a little to make sure I do have logs and revert
09:27:30  <swaagie>I'll take a quick peek along
09:32:55  * mesoquit (Remote host closed the connection)
09:36:16  <pjbrinck>swaagie: ok, maybe have some explanation for no logs, I get 404 on all calls to the server, seems I get this from the platform and not from my server, then of course I dont see any logs... this seems to happen from time to time, maybe when I deploy new versions
09:37:09  <pjbrinck>swaagie: my normal work around is then to stop/start server to get rid of general 404, not a good situation, but one I am living with as long as I only develop
09:38:40  <swaagie>pjbrinck: our platform does not spawn 404's we only got 400 for stopped apps and 502's for unreachable apps
09:39:01  <swaagie>that 404 is the default express's
09:39:14  <swaagie>still it's weird it just goes to that state
09:39:29  <swaagie>mind if I restart the app?
09:39:50  <pjbrinck>swaagie: odd, let me stop/start app and see what I get, now Im fighting 401 n the webops, brb
09:39:57  <pjbrinck>ok plz do
09:40:16  <pjbrinck>and let me know when and I will rerun test scripts against it
09:42:04  <swaagie>pjbrinck: I just restarted it index responds with a 404 though
09:42:15  <swaagie>it,
09:42:34  <pjbrinck>swaagie: meaning?
09:42:40  <swaagie>dunno
09:42:49  <pjbrinck>swaagie: an Express thing?
09:42:49  <swaagie>other than that it is programmed that way
09:43:25  <swaagie>well I requested http://jungle.jit.su/ and if there is no index page set it will just respond with 404 as excpected
09:43:40  * mdedetrichjoined
09:43:50  <swaagie>but i'm not sure if that route should even exists, thats up to you ofc
09:44:05  <pjbrinck>swaagie: ok, I dont have and index route
09:44:40  <swaagie>ah k then that 404 is normal, just like http://jungle.jit.su/any/random/path would return a 404
09:45:12  <pjbrinck>swaagie: i have an extremely simple request that should respond every time: http://jungle.nodejitsu.com/id but that too responds 404
09:45:57  <swaagie>yeah but thats express as well, so the route is not available
09:46:13  <pjbrinck>swaagie: true
09:46:23  <swaagie>o>O
09:46:28  <swaagie>I got a 401 now
09:46:30  <swaagie>ont he same route
09:46:40  <pjbrinck>swaagie: just did that too
09:46:44  <swaagie>haha
09:46:45  <swaagie>ok
09:46:47  <swaagie>was like wtf
09:46:50  <pjbrinck>swaagie: after stop/start in console
09:47:08  <swaagie>hmm
09:47:16  <pjbrinck>swaagie: a few more stop/start and it will normally normalize
09:47:21  <swaagie>pjbrinck: ok so you only did a start/stop and now its back to normal again?
09:47:39  <pjbrinck>swaagie: well 401 og get id is not normal
09:47:48  <pjbrinck>swaagie: but better that 404
09:47:53  <swaagie>are you storing states anywhere
09:48:01  <pjbrinck>swaagie: NOPE
09:48:21  <pjbrinck>swaagie: well, no is such a strong answer, let me correct, NOT TO MY KNOWLEDGE
09:48:29  <swaagie>express templates will cache if possible though
09:48:54  <pjbrinck>swaagie: but U may be on to something, help me out, what would be "storing state"
09:49:19  <pjbrinck>swaagie: OC, Im storing state in DB (mongo)
09:49:36  <pjbrinck>but certainly not in conjunction with get id
09:49:48  <swaagie>well in its most simple form, just a local module variable that is global to all routes and gets written by a route infecting others
09:50:14  <pjbrinck>swaagie: true
09:51:22  <swaagie>accidental 'globals' happen ofc, the 401 for all random routes now seems a bit akward, is there a regexp matcher for routes?
09:52:06  <pjbrinck>swaagie: but then I should have same problem in localhost I would think, codebases are identical
09:52:18  <swaagie>true
09:52:31  * mdedetrichquit (Quit: Computer has gone to sleep.)
09:52:56  <pjbrinck>swaagie: wonder if Express uses env vars, that may be diff in two env
09:53:04  <swaagie>yeah that will be diff
09:53:12  <swaagie>NODE_ENV will be production on the drone
09:53:29  <swaagie>and defaults to development on local
09:53:52  <swaagie>atleast I thought app.get('env') would return development by default
09:54:10  <pjbrinck>swaagie: so if I set NODE_ENV to development on Jitsu, I should be aligned?
09:54:39  <swaagie>yeah you can supply the env vars in the package.json
09:54:44  * alxjoined
09:55:04  * mokesjoined
09:55:08  <swaagie>eventually you'd want to keep that as production after deploying though
09:55:42  <pjbrinck>swaagie: changing NODE_ENV thru console now and retrying
09:55:57  <swaagie>thats also an option
09:58:55  <pjbrinck>+swaagie: oh no, app restarting but never starting, cannot stop/start it either, seems stuck in changing env_var
09:59:44  <pjbrinck>+swaagie: or maybe that was a browser refresh err, my bad
10:00:00  <swaagie>now its 404 again
10:00:35  <swaagie>ow well id is not
10:00:38  <swaagie>my bad
10:01:04  <pjbrinck>+swaagie: well get id worked, so now im resetting env var to production, just to test diff
10:01:07  <swaagie>so yeah I guess authentication is activated on NODE_ENV=produ..
10:01:19  <swaagie>might be some middleware
10:01:46  <pjbrinck>+swaagie: odd, bc this is a prob i get from time to other, its periodically and not contsant
10:01:53  * xobbobjoined
10:02:45  <pjbrinck>+swaagie: ok, now I reset env var to production, and now get id works as supposed to
10:03:17  <pjbrinck>+swaagie: so a little forth and a little back and things are back in place, seems like a state of some sort, like U suggetsed
10:04:38  <swaagie>hmm ok, I think the problem is somewhere in the app logic, probably a state somewhere, however if it isn't and you find a reproducible error on our side I will admit my wrong and we'll fix it ;) don't hesitate to spam our channel
10:07:24  <pjbrinck>+swaagie: yeah thanks, I will see if I can reproduce, normally it works the other way arround: my system will work fine until I redeploy with app tested on localhost, then it will hang with 404 and 401 until I stop/start (and now also change env vars) a few times and then it will work again like it did on localhost
10:07:54  <pjbrinck>+swaagie: back to first prob, missing logs
10:09:07  * alxquit (Remote host closed the connection)
10:09:45  <pjbrinck>+swaagie: but maybe thats bc Im back in production mode on nodejitsu?
10:10:20  <swaagie>if you saw more logs during dev, then its again express or some other middleware not exposing the logs if !development
10:10:29  <swaagie>we really tend to be least instrusive
10:10:51  <swaagie>we spawn the node process/app listed by package.json and thats it
10:11:00  <swaagie>you should be in full control
10:11:03  <pjbrinck>+swaagie: I understand, I will play with dev/prod a little
10:12:03  <pjbrinck>+swaagie: so what remains is the missing logs on the devops only (I see a little on jitsu but none on devops), but I can lve with having them in jitsu, in fact I like that better
10:12:49  <pjbrinck>+swaagie: thanks for Ur help, I will revert when/if I find a pattern to my redeploy issuees
10:12:52  <swaagie>pjbrinck: webops is because there not a lot of streaming logs and jitsu logs tail gets some of the backlog
10:13:18  <swaagie>I'm working on webops atm to also get some backlog
10:13:25  <swaagie>just to acknowledge it is working
10:13:46  <pjbrinck>+swaagie: one last thing, as I am rather new to all this, how do I set env vars in package?
10:13:48  <swaagie>I think as soon as express will expose it logs you'll see stuff streaming in
10:15:14  <swaagie>pjbrinck: that was my bad, you can set them from the cli, see https://www.nodejitsu.com/documentation/jitsu/env/
10:16:24  <pjbrinck>+swaagie: thank U a bunch
10:17:29  <swaagie>pjbrinck: no problem your welcome, happy coding, don't hesitate to contact us
10:18:09  * mokesquit (Remote host closed the connection)
10:18:12  * sol_invictusjoined
10:19:18  * InconceivableBquit (Quit: Computer has gone to sleep.)
10:20:47  * thiaminequit (Ping timeout: 250 seconds)
10:26:15  * benjaminbenbenjoined
10:28:24  * mokesjoined
10:29:20  * ionellaquit (Remote host closed the connection)
10:29:44  * leichtge_quit (Remote host closed the connection)
10:36:03  * Tom0101quit (Remote host closed the connection)
10:41:55  * ionellajoined
10:42:04  * sol_invictusquit (Remote host closed the connection)
10:42:56  * sol_invictusjoined
10:45:44  * armijoined
10:49:23  * mokesquit (Remote host closed the connection)
10:50:00  * ionellaquit (Remote host closed the connection)
10:52:20  * armiquit (Quit: Page closed)
10:55:48  * joshonthewebquit (Quit: Computer has gone to sleep.)
10:57:16  * mdedetrichjoined
11:00:07  <pjbrinck>+swaagie: want to try out stopping/starting app a few times to see if U can find pattern in when it throws 404/401 vs 200?
11:01:33  * mokesjoined
11:01:41  <swaagie>pjbrinck: I'll give the app logic a more thorough peek
11:02:13  * tonistquit (Quit: tonist)
11:02:46  <pjbrinck>+swaagie: I inserted a console.log('Hello World'); in the first app.use of Express to see if I hit this before 404/401
11:03:19  <pjbrinck>now I dont get 404/401, so I suggets U try stop/start a few times, every time do a get id
11:03:31  <pjbrinck>that is GET http://jungle.nodejitsu.com/id
11:03:42  * mdedetrichquit (Ping timeout: 264 seconds)
11:03:49  * tonistjoined
11:04:14  <swaagie>http://jungle.nodejitsu.com/id/asdasd returns id is that expected?
11:04:35  <swaagie>a 404 with id as content
11:05:22  * mokesquit (Remote host closed the connection)
11:07:23  <pjbrinck>+swaagie: I have several servers initiated, the one to look into is the one behind port 80, code located in /jungle/solution/servers/dispatcher/server.js
11:08:06  <swaagie>serveral servers? do note that we reroute all external traffic to port 80
11:08:39  * mokesjoined
11:08:42  <pjbrinck>+swaagie: one listening on port 80, others on other ports, those are all internal server to server calls
11:08:54  <swaagie>yeah ok internal should be possible
11:09:10  <pjbrinck>+swaagie: so server on port 80 calls servers on other ports, or they call one another
11:09:37  <pjbrinck>+swaagie: im going to lunch will be back in ab 30 mins and catch up with U
11:09:41  <swaagie>roger
11:10:29  * jbprosquit (Quit: jbpros)
11:13:05  * mdedetrichjoined
11:16:43  * tonistquit (Quit: tonist)
11:19:40  * alxjoined
11:19:52  * sol_invictusquit (Remote host closed the connection)
11:20:24  * papachanjoined
11:20:46  * sol_invictusjoined
11:20:54  * ionellajoined
11:21:25  * papachanpart
11:24:13  * alxquit (Ping timeout: 246 seconds)
11:32:18  * ionellaquit (Remote host closed the connection)
11:33:24  * benjaminbenbenquit (Quit: benjaminbenben)
11:38:09  * leichtgewichtjoined
11:43:20  * daviddiasjoined
11:49:39  <pjbrinck>+swaagie: back from lunch
11:50:32  <swaagie>pjbrinck: yo, most logic seems sane, I doubt I'll find it any quicker than you, something to look out for might be unstarted subservers or any race condition spawning from callbacks being called to early. Also the logging of colored message of the express connect middleware (logger) seems broken. The last is something we should fix, you can remove the format
11:50:32  <swaagie>'dev' from logger for now to see the logs of request.
11:51:04  * mokesquit (Remote host closed the connection)
11:51:44  <pjbrinck>+swaagie: ok
11:52:09  <pjbrinck>+swaagie: did U try to stop/start to see if U get diff behavior
11:52:32  <swaagie>so basically stop/start/redeploy after logging some critical point while keeping a jitsu logs tail open in another terminal
11:52:42  <swaagie>pjbrinck: yeah, even redeployed
11:53:00  <pjbrinck>+swaagie: and it came back up nicely every time?
11:53:29  <swaagie>did like 3 times, and went fine i'll do a few more
11:53:39  <pjbrinck>+swaagie: ok
11:53:57  * sreeixquit (Quit: sreeix)
11:54:35  <pjbrinck>+swaagie: so now U see a series of 200's, yet U saw a series 404's and 401's and U trust I didnt change code (except for the Hello World log)
11:54:51  <swaagie>yeah agree
11:54:58  * jbprosjoined
11:55:05  <pjbrinck>+swaagie: what could explain such other than possibly environmnet changees/depends
11:55:08  * xobbobquit (Quit: xobbob)
11:55:31  <swaagie>any race condition or perhaps a server not starting, although I haven't seen that yet
11:55:54  * calwebjoined
11:56:02  <pjbrinck>+swaagie: yeah race conditions or non-initialize vars possibly?
11:56:24  <pjbrinck>+swaagie: but in the GET id example I only hit 1 server
11:56:39  * spoluquit (Read error: Operation timed out)
11:56:48  <swaagie>yeah but like
11:56:48  <swaagie>[08/26 13:54:27 GMT+0200][out] request server listening on port 3110
11:56:48  <swaagie>[08/26 13:54:27 GMT+0200][out] dispatcher server listening on port 80
11:56:48  <swaagie>[08/26 13:54:26 GMT+0200][out] consumer server listening on port 5111
11:56:48  <swaagie>vs
11:56:50  <swaagie>[08/26 13:56:17 GMT+0200][out] user server listening on port 4110
11:56:50  <swaagie>[08/26 13:56:17 GMT+0200][out] request server listening on port 3110
11:56:50  <swaagie>[08/26 13:56:17 GMT+0200][out] dispatcher server listening on port 80
11:57:02  <swaagie>could spawn unwanted behaviour without noticing it
11:57:09  <pjbrinck>+swaagie: OK I U
11:57:29  <swaagie>but thats arguing from the sideline a bit
11:57:43  <swaagie>as I don't know how all stuff ties into each other
11:57:55  <pjbrinck>+swaagie: Ur suggesting the multipe server initiation may have one server trip the other server
11:57:58  <pjbrinck>OC
11:58:08  <swaagie>something like that
11:58:22  <swaagie>I believe (not entirely sure) we request the app once on start to check its state
11:58:26  <pjbrinck>+swaagie: let me just start server on port 80 then
11:58:33  <pjbrinck>and just do GET id
11:58:43  <pjbrinck>and see if I can have it respond 404/401
11:59:07  * tonistjoined
11:59:10  <swaagie>now its in 401
11:59:23  <pjbrinck>+swaagie: after a restart?
11:59:39  <swaagie>yup did a stop start, but there is nothing unusual about the server order
11:59:42  <pjbrinck>sounds like a race condition could be in play here
11:59:51  <swaagie>infact the dispatcher is initialized last
12:00:12  <pjbrinck>yeah I initiate then in post order
12:00:20  <pjbrinck>callee before caller
12:00:48  <swaagie>If I was you I would try to reduce all code as much as possible to focus it down to any part of the app and see where you can and cannot reproduce it anymore
12:00:50  <pjbrinck>I will redeploy with dispatcher (port 80) only
12:01:10  <pjbrinck>and see if I can reproduce it
12:01:11  * ejeklintquit (Quit: ejeklint)
12:01:26  <pjbrinck>then if I can, I will cut down on dispatcher code
12:02:03  <swaagie>cool
12:02:03  <pjbrinck>+swaagie: thank U a lot for al ur help, feel free to get back to me if U come up with other ideas
12:02:08  * ejeklintjoined
12:03:53  * sol_invictusquit (Remote host closed the connection)
12:06:30  <swaagie>pjbrinck: sure no problem
12:06:39  <swaagie>I'll make sure we'll get that colored logging fixed
12:06:44  <swaagie>might be some character it is tripping over
12:06:51  <pjbrinck>cool
12:09:04  <pjbrinck>+swaagie: to ease my investigation... would it be fair to assume, that I can do any redeploy or any stop/start or any restart and ALWAYS expect an error free system to run?
12:10:00  <swaagie>yup you can expect that or drones are fully purged/reset if an app is moved to another drone
12:10:19  <swaagie>in addition until now we/I haven't seen any other issue similar to this one
12:10:36  <swaagie>if it would be a general failure mad people would be streaming in by now
12:11:02  <swaagie>not sure about the exact number of express servers running on our architecture but it will probably be in the dozen
12:11:09  <swaagie>eh hundreds even :P
12:15:21  <swaagie>pjbrinck: obvisouly there is always an exception to the rule, like the edge case of colored logging. Hence I'm keeping a close eye on yur
12:15:24  <swaagie>your progress*
12:15:50  * sol_invictusjoined
12:16:01  <pjbrinck>+swaagie: well I designed an architecture where i can scale out on any number of Express servers, but in this setup U only saw 6 or so
12:16:13  * mokesjoined
12:16:39  <pjbrinck>+swaagie: would a better solution be to create a number of nodejitsu apps each with one Express server?
12:17:09  <pjbrinck>+swaagie: thats where I want to go regardless when I go towards production
12:18:24  <pjbrinck>+swaagie: I suspect seperate apps run in isolation, so that would rule out any possible race condition between any number of Express servers?
12:18:38  <swaagie>well its what most do since we do the horizontal scaling then, but your solution should be perfectly applicable
12:18:51  <swaagie>yeah it might be even an internal express thingy
12:18:54  <swaagie>not sure about that though
12:19:17  <swaagie>as the express.app() returns a new instance I believe
12:19:27  <pjbrinck>+swaagie: I think Ur line of reasoning around the race condition seems fair
12:19:55  <swaagie>still each instance can include the same module which might retain some global state
12:21:04  <pjbrinck>+swaagie: yeah but not across multiple Nodejitsu apps I suspect, tahts why I asked ab isolation
12:21:24  <swaagie>some part of the routing module for instance, caching the function to use on /id, if another servers gets called before the 80 one it might cache a 404 because it has no id route
12:21:25  * armijoined
12:22:07  <swaagie>pjbrinck: if each server runs on an individual drone they are incapable of infecting
12:22:25  <swaagie>each drone is a completely seperate instance with just one app running
12:22:43  * sandfoxjoined
12:23:01  <pjbrinck>+swaagie: but if I run 5 apps each with 1 server as opposed to 1 app with 5 servers all on one drone, would that make a diff
12:24:14  * ionellajoined
12:25:45  <swaagie>hmm how would you want to seperate the 5 apps on the single drone? I mean you got only one subdomain for 5 apps then
12:26:11  <swaagie>or you mean 5 apps, 1 app per drone, each with 1 server
12:26:36  <swaagie>well it would probably resolve this issue, but without knowing exactly whats causing it, I woulnd't bet any money ont it
12:26:54  * mesojoined
12:27:15  * johnmartyjoined
12:28:29  * andreypoppquit (Quit: andreypopp)
12:30:06  * andreypoppjoined
12:37:22  * benjaminbenbenjoined
12:39:25  <swaagie>pjbrinck: here's a thought, our port rerouting may be non-deterministic (asking sr. devops atm to be sure) meaning any initial listen from any port might be rerouting to 80
12:39:30  * spolujoined
12:39:42  <swaagie>meaning we're quering against /id on another app than the expected 80
12:40:07  <swaagie>what you could try is defer spawning of those other server instances until the callback of the main app on port 80 is called
12:41:25  <pjbrinck>+swaagie: are U asking me to spawn and respawn secondary serveres on each call to dispacther?
12:41:37  <swaagie>no
12:41:57  <swaagie>only after the main app (the port 80) one is done initialization
12:42:34  <swaagie>so basically inside the callback of the express.listen(80, function () { // spawn other servers here }
12:43:05  <pjbrinck>but I init all servers in post order, e.g. port 8000, port 7000, ... port 80 to be sure callees are up when caller runs
12:43:33  <pjbrinck>now I will try to timeout a few secs between inits to avoid race conditions during init
12:43:55  * calwebquit (Quit: Leaving.)
12:44:10  <pjbrinck>so U wat me to init 80 (dispatcher) first?
12:44:10  <swaagie>not sure exactly which post order? as far as I saw in the app code each server is spawned in parallel
12:44:16  <swaagie>yup
12:44:27  <pjbrinck>heres what I currently do
12:44:35  <pjbrinck>server A calls B calls C
12:44:44  <pjbrinck>so I init server C before B before A
12:45:11  <pjbrinck>to ensure accessibility on C when B calls C and on B when A calls B
12:45:16  <swaagie>aint that the other way around, if server A calls B then A should be inititialized before B
12:45:24  <pjbrinck>well NO
12:45:42  <pjbrinck>because if A calls B then B should be available before A ninits
12:45:49  <pjbrinck>inits
12:45:55  * swaagiedownloading snapshot again ;)
12:46:05  <pjbrinck>right?
12:46:06  <pjbrinck>ok
12:46:06  <swaagie>so yeah then it should be init server B -> init server A
12:46:19  * paralleljoined
12:46:28  <pjbrinck>and thats what I do, no I will insert a delay between each init to avooid possible race cond
12:46:51  <pjbrinck>or I could do it inside completion of the former
12:46:56  <swaagie>if you init a server from inside the listen callback that shouldn't be nessecary
12:47:04  <swaagie>exactly
12:47:11  <swaagie>hence there is a major race condition now
12:47:22  <swaagie>because there is no telling which server is spawning first
12:47:43  <swaagie>unless you got a async.series/waterfall wrapper orsomething
12:47:52  <pjbrinck>I agree, bt if I init A inside B I will couple the servers in many diff server files
12:48:04  <pjbrinck>have a look at start.js
12:48:23  * Dorphernjoined
12:48:24  <pjbrinck>thats where I control the number of servers
12:48:35  * spoluquit (Ping timeout: 256 seconds)
12:48:56  <swaagie>yeah but the spawn parallel
12:49:01  <swaagie>they*
12:49:19  <swaagie>the executing flow will not halt at each new to wait for the next
12:49:32  <swaagie>next=it to complete*
12:49:45  * jcrugzzjoined
12:50:09  <pjbrinck>what if I do a setTimeout between each init
12:50:35  <pjbrinck>IK they dont halt now, thats wh I want to insert setTimeout of maybe 2000 ms
12:50:41  <pjbrinck>between each server inint
12:50:46  <swaagie>pjbrinck: the best way to observe what I mean is to add console.log('something') between each new server init call, all the somethings will be logged before the listens expose there log
12:50:57  <swaagie>that will do nothing
12:51:00  <pjbrinck>true
12:51:05  <swaagie>what you want is a async.series wrapper
12:51:11  <swaagie>https://github.com/caolan/async
12:51:14  <pjbrinck>ups why wont it do anything with setTimeout
12:51:32  <pjbrinck>ok cool let me look into thatt
12:51:49  * frenchtoastjoined
12:51:56  <swaagie>yeah ofc you could do something like setTimeout(server D, 1000) setTimeout(server C, 2000) but I consider that hacky
12:52:05  <swaagie>there are way cleaner methods
12:52:56  <swaagie>like the async module or just exposing each server without calling listen and then just cascade each listen call inside start.js
12:52:59  <pjbrinck>Ur suggesting I do
12:53:00  <pjbrinck>async.series([ function(){ ... }, function(){ ... } ]);
12:53:19  <swaagie>yup
12:53:43  <swaagie>and setting up the main first
12:53:44  <pjbrinck>agree, much cleaner
12:54:04  <swaagie>so our architecture will make sure that main script is bound to 80
12:54:14  <swaagie>which it already is
12:54:26  <swaagie>pjbrinck: hehe your going to love async for a lot of stuff you'll do
12:54:32  <swaagie>flow control is essential
12:54:50  <pjbrinck>hmmmm, U said, main script is bound to 80
12:55:00  <swaagie>well you want your main entry to be bound to 80
12:55:02  <pjbrinck>but I specifically have dispatcher server listen to 80
12:55:04  * ionella_joined
12:55:17  <pjbrinck>I suspect it will regardless of order
12:55:27  <swaagie>yeah but we just pickup on the first listen, as we don't know what port people will use
12:55:31  <swaagie>nah
12:55:38  <pjbrinck>nah?
12:55:42  <swaagie>we can't maintain order
12:55:48  <swaagie>nah=no* ;)
12:56:13  <swaagie>basically you could start any port at any point in time, if we wait for 80 it might never happen, because somebody just used 8080
12:56:21  <swaagie>could*
12:56:26  * parallelquit (Remote host closed the connection)
12:56:32  <pjbrinck>are U saying that http.createServer(app).listen(80, func()) will not listen to port 80
12:56:39  <swaagie>so the first listen is our what we use regardless and bind that to port 80
12:56:43  <swaagie>not by default
12:56:48  <swaagie>simply because we can't
12:56:54  <pjbrinck>ahhh ok
12:57:01  <pjbrinck>so heres a race condition
12:57:14  <swaagie>if it is the first app to listen on that port 80 we will route it to 80 ofcourse
12:57:29  <swaagie>but somebody could also do listen(8080, and then we'll just bind that to 80
12:57:43  <swaagie>becasue there is no telling the developer will actually bind someting to 80 as well later on
12:57:47  <pjbrinck>so if a secondary server on e.g. 7000 inits first U will ignore 7000 and use 80?
12:58:08  <swaagie>well how do we know its secondary ;)
12:58:12  <swaagie>so yeah
12:58:14  <pjbrinck>U dont
12:58:29  <pjbrinck>U would have to trust that one server is bound on 80,
12:58:40  <pjbrinck>now THAT makes a ot of sense
12:58:46  <swaagie>hence we reroute any listen
12:58:54  * ionellaquit (Ping timeout: 264 seconds)
12:59:01  <swaagie>anyways your logic will work
12:59:02  <pjbrinck>not that U dont trust that I will listen to 80 eventually
12:59:14  <pjbrinck>but that this causes my app to fail
12:59:16  <swaagie>if your main app listens first
12:59:20  <swaagie>then the others can spawn in parallel
12:59:28  <pjbrinck>I get it
12:59:45  <pjbrinck>thats why only once every other thrusday this will init corrctly
12:59:52  <swaagie>so basically you want the dispatcher to to do module.exports = express.app()
13:00:04  * Slyquit (Remote host closed the connection)
13:00:22  <pjbrinck>OK, I will rework my init logic based on this knowledge
13:00:28  * Slyjoined
13:00:39  <swaagie>and in start.js do dispatcher.listen(80, function () { console.log('main app started on port 80'); new Ikea; new server2; new server3 })
13:00:40  <pjbrinck>that also explains why I had diff exp on localhost and on nodejitsu
13:00:49  <swaagie>well not really
13:00:56  <swaagie>on localhost this could have happened as well
13:01:03  <swaagie>ow no ofc not :P
13:01:04  <swaagie>sorry
13:01:12  <pjbrinck>ok
13:01:18  <swaagie>there's no rebinding ofc
13:01:23  <swaagie>of ports that is
13:01:23  <pjbrinck>exactly
13:01:32  <pjbrinck>THANKS a lot for that info
13:01:40  <pjbrinck>like I said, let me rework it
13:01:54  <swaagie>pjbrinck: you wouldn't need async.series btw if those subservers are not dependent on each other to start first
13:02:12  <swaagie>pjbrinck: no problem, glad we got to a culprit
13:02:14  <swaagie>the*
13:02:16  <pjbrinck>true, none of the servers call oneanothe at init
13:02:23  * swaagiesucks at typing tbh
13:02:27  <pjbrinck>hahahahaa
13:04:50  * nmanousosjoined
13:05:10  <nmanousos>hi, anyone from nodejitsu around I? quick question
13:05:31  <Sly>nmanousos: what's up?
13:05:59  <swaagie>pjbrinck: slight adjustment to all just told, we actually listen to the last server port listened to
13:06:04  <swaagie>so that would require async.series
13:06:29  <swaagie>or even async.parallel spawning the first 4 servers in the parallel and the main in the callback
13:06:39  <swaagie>its just reversing the order of what we discussed
13:07:05  <nmanousos>Sly: hi, i am seeing some behavior in one of my apps that looks like there are two drones running but the admin UI only shows one
13:07:40  <nmanousos>Sly: i have a cron job that sends emails every hour, over the weekend all emails starting being duplicated
13:07:57  <pjbrinck>+swaagie: so Ur saying I may init A on 7000, B on 6000 and C on 5000 and C is redirected to 80
13:08:07  <nmanousos>Sly: I saw this happen before when I inadvertently increased the drones to 2 for this app, and had two cron jobs running for the same task
13:08:10  <swaagie>yeah
13:08:18  <nmanousos>Sly: wondering if something similar is happening
13:08:19  * kevino80joined
13:08:20  <swaagie>pjbrinck: correct instead of A on 80
13:08:26  * calwebjoined
13:08:38  <Sly>nmanousos: do you have it set for 2 drones right now? If so, that could be it.
13:08:40  <swaagie>I thought it would be the first listen, but actually its the last
13:08:44  <pjbrinck>+swaagie: and if after 2 mins I then init D on 4000, will C revert to 5000?
13:08:49  <nmanousos>Sly: no, just 1
13:08:49  <pjbrinck>and D go to 80?
13:09:03  <nmanousos>Sly: but all signs are pointing to two running, it's weird
13:09:16  <Sly>nmanousos: when's the last time you deployed?
13:09:18  <Sly>Or started?
13:09:22  <nmanousos>yesterday
13:09:40  <swaagie>pjbrinck: not sure about that tbh
13:09:53  <Sly>nmanousos: which app is it for?
13:10:01  <nmanousos>coolence-web
13:10:05  <pjbrinck>plz check and revert
13:15:41  <swaagie>pjbrinck: if you spawn one 2 mins later it would brute force itself over the current, the last listened port will be rerouted to 80, note that the ports itself do not change
13:15:53  <swaagie>its external traffic we proxy to the correct port anyways
13:16:03  <swaagie>so 80 -> 3000 if the app was listening on 3000
13:16:14  <swaagie>direct access to 3000 is blocked however
13:16:32  <pjbrinck>+swaagie: so here is what I understand
13:16:34  <swaagie>pjbrinck: so in conclusion you want your main app to spawn last
13:16:59  <pjbrinck>all servers will INTERNALLY respond to ports listened on
13:17:09  <pjbrinck>as specified in init
13:17:12  <swaagie>yup
13:17:23  <pjbrinck>however, every new server, whenever it is init
13:17:34  <pjbrinck>will get the EXTERNAL cal on 80
13:17:53  <pjbrinck>so if dispatcher server, which I init last
13:18:00  <swaagie>yes 80 traffic will reroute to that new server port
13:18:21  <pjbrinck>for some reason is a bit fast and a secodary server a bit slow
13:18:32  <pjbrinck>I will see the secondary server on 80
13:18:47  <pjbrinck>it all makes a lot of sense
13:19:05  <swaagie>in practice you can do async.parallel(// each subserver, function parallelComplete() { // init the main dispatcher } )
13:19:14  <Sly>nmanousos: I found one stray process, so hopefully that will solve it.
13:19:26  <nmanousos>Sly: nice! thanks so much
13:19:43  * daviddiasquit (Remote host closed the connection)
13:20:06  <pjbrinck>+swaagie: ok, just installed async, will try it out
13:20:18  * daviddiasjoined
13:20:32  <swaagie>pjbrinck: roger, gl
13:20:40  <pjbrinck>thx
13:20:49  <nmanousos>Sly: i really appreciate it
13:20:52  <nmanousos>cya
13:21:02  * nmanousosquit (Quit: Page closed)
13:23:22  * spolujoined
13:23:56  * paralleljoined
13:25:09  * daviddiasquit (Ping timeout: 276 seconds)
13:25:48  * sreeixjoined
13:29:19  * johnmartyquit (Quit: Leaving.)
13:29:20  * kevino80quit (Remote host closed the connection)
13:30:28  * kevino80joined
13:31:33  * parallelquit (Remote host closed the connection)
13:32:19  * devdazedjoined
13:32:27  * jmar777joined
13:40:35  * frenchtoastquit (Ping timeout: 241 seconds)
13:41:01  * ggoodmanjoined
13:41:39  * paralleljoined
13:41:51  * frenchtoastjoined
13:41:53  <ggoodman>Hi guys, it seems that every Monday morning my site becomes inaccessible. From what I can tell, it doesn't go down, it simply stops having traffic routed to it. Why is this happening and how can I prevent it?
13:42:31  <ggoodman>Users are presented with the 404, *.plnkr.co is not found message.
13:44:18  <Sly>ggoodman: your homepage works fine for me. Where are you seeing this error at?
13:44:18  <jmar777>ggoodman: can you still hit the site using the *.jit.su url?
13:44:41  <ggoodman>its back up... I restart the server when I notice the issue
13:44:51  <ggoodman>but its like clockwork on Monday morning
13:44:59  <ggoodman>jmar777: haven't tried that
13:46:11  * itdontworksonquit (Ping timeout: 250 seconds)
13:46:39  * c4milojoined
13:48:31  * jbprosquit (Quit: jbpros)
13:49:30  <ggoodman>Sly: do you guys have some job that runs on monday am or something?
13:49:38  <Sly>ggoodman: not that I'm aware of.
13:49:39  <Sly>chjj: ^
13:50:31  * johnmartyjoined
13:50:41  <chjj>ggoodman: we have jobs that run daily and monthly, not specifically on monday though. why do you ask?
13:50:47  * parallelquit (Remote host closed the connection)
13:50:50  * jgablejoined
13:51:00  <ggoodman>chjj: the last couple Mondays my site goes 404
13:51:08  <ggoodman>inexplicably
13:52:03  <ggoodman>that time also corresponds to a big spike in traffic
13:52:27  * jcrugzzquit (Ping timeout: 276 seconds)
13:53:33  <chjj>ggoodman: hmm, the jobs that do run wouldn't be affecting that. i'm guessing it's something else and monday might just be coincidental. will investigate.
13:53:59  <ggoodman>ok. just looking at analytics and last monday it wasn't in the morning after all
13:54:12  <ggoodman>2pm it dropped off the map
13:55:35  <ggoodman>this morning somewhere b/w 8am and 9:30am
13:58:23  * calwebquit (Quit: Leaving.)
13:59:56  * calwebjoined
14:01:29  * nmanousosjoined
14:02:36  <nmanousos>Sly: back again, same issue - is it possible there still is another process running?
14:03:03  <Sly>Yeah, it's possible.
14:03:23  <nmanousos>Sly: i am tailing my logs, and I see this cron job send one email, but always two emails are received
14:03:44  <nmanousos>the email smtp details look like the requests are coming from two separate IPs
14:03:59  <Sly>Are they 10.* IPs?
14:04:05  <nmanousos>checking
14:04:16  <Sly>That would help a ton if so.
14:04:38  <nmanousos>yes they are
14:04:43  <Sly>AWESOME.
14:04:55  <Sly>What are they? Whichever one you're not running on now is the one I need to burn with fire.
14:05:14  <nmanousos>10.66.194.13, 10.68.170.133
14:05:32  <Sly>And you said this is for coolence-web, right?
14:05:35  <nmanousos>yes
14:06:08  <Sly>Well, unfortunately our IPs are 10.112.*, so those aren't our's...
14:06:13  <Sly>Must be coming from the mail route...
14:06:39  <nmanousos>ah, yeh
14:06:48  <nmanousos>i was looking at X-received-by
14:06:53  <nmanousos>in the received by, they are both from 10.112.126.234
14:07:18  * Dorphernquit (Ping timeout: 264 seconds)
14:07:31  <nmanousos>this is so weird, i can see the send email function being called only once
14:07:33  <Sly>Still not one of our servers. Must be the mail server.
14:08:08  <nmanousos>i talked with sendgrid, they are saying that there are definitely two requests coming from my app, but as far as i can see it's only sending one
14:10:52  * calwebquit (Quit: Leaving.)
14:11:32  <nmanousos>and - this only happens when my "send emails" function is called via cron
14:11:43  <nmanousos>i can call it manually and it sends normally
14:11:55  * andreypoppquit (Quit: andreypopp)
14:12:06  <Sly>Sounds like it might be something to do with that cron being called twice then.
14:12:29  <nmanousos>yeh
14:14:25  * Samuel_Roldanjoined
14:14:29  * calwebjoined
14:14:39  <Sly>nmanousos: yeah. I just checked all of the servers it's saying you've deployed to recently, and they're all active by someone else and only one node process running.
14:14:55  <nmanousos>ok, hmm
14:15:02  <nmanousos>i will get to the bottom of this
14:15:10  <nmanousos>thank you for looking
14:16:32  * kenperkinsjoined
14:16:37  * ejeklintquit (Quit: ejeklint)
14:18:58  <nmanousos>Sly: one more thought / question
14:19:13  <nmanousos>locally, even with this cron job running, it sends only one
14:19:22  <nmanousos>i can only reproduce this in production
14:19:35  <Sly>Try `NODE_ENV=production npm start`
14:19:38  <Sly>And run in production locally
14:19:47  <nmanousos>is there a way to examine the node module versions? maybe there is a version mismatch of the cron module in prod?
14:20:18  * niixjoined
14:20:31  <niix>Hello! I'm having a problem deploying my app. Here is the traceback https://gist.github.com/niix/edb69e1d27bc7ed47d5b
14:20:42  <niix>the weird thing is it works completely fine locally and loads in my settings
14:20:51  <mmalecki>niix: yo
14:20:58  <Sly>nmanousos: one minute.
14:20:58  <nmanousos>i dont follow - i sent my NODE_ENV to production locally
14:21:00  <mmalecki>niix: is settings in your .gitignore, per chance?
14:21:19  <niix>mmalecki: heh, that's it!
14:21:29  <mmalecki>niix: there you go :-). happy to help!
14:21:48  <niix>mmalecki: I deployed this app before, but I forgot about that until you reminded me haha
14:21:49  <niix>thanks!
14:21:51  <mmalecki>niix: if you want to keep it there, create an empty .npmignore
14:21:55  <mmalecki>word!
14:22:10  <niix>empty npmignore will help?
14:23:49  <mmalecki>yup
14:24:08  <mmalecki>we'll use .npmignore instead and since it's empty, no files will be ignored
14:24:22  <mmalecki>you can put some entries there too, if you don't want to deploy something
14:24:57  * sandfoxquit (Quit: sandfox)
14:26:09  * c4miloquit (Remote host closed the connection)
14:26:44  * x_orquit (Ping timeout: 260 seconds)
14:32:20  * calwebquit (Quit: Leaving.)
14:32:37  * niixquit (Remote host closed the connection)
14:33:03  * jcrugzzjoined
14:34:00  * ejeklintjoined
14:34:35  * calwebjoined
14:34:44  * mokesquit (Remote host closed the connection)
14:35:15  <swaagie>nmanousos: found your problem, there is still a old node process runnning in our old architecture
14:35:25  <nmanousos>woohoo!
14:35:38  <nmanousos>nice
14:35:42  <swaagie>gonna purge it with fire now
14:35:44  <nmanousos>did you kill it?
14:35:45  <nmanousos>cool
14:35:47  * mokesjoined
14:36:58  <nmanousos>was it something i did that caused it?
14:37:06  <nmanousos>it started on Friday i think
14:37:27  <swaagie>nmanousos: not sure its a nasty bugger, killing the process seems to spawn more of the same
14:37:57  <swaagie>o my bad
14:37:57  <nmanousos>crazy
14:38:08  <swaagie>it seems that drone actually is infected with som other zombie process
14:38:18  <swaagie>glad our new arch does not have those failures anymore
14:38:49  <swaagie>nmanousos: it should be silent now, could you test the cron again?
14:38:56  * c4milojoined
14:39:08  <ggoodman>little did you know but skynet was hours away from deployment on your old arch
14:39:27  <nmanousos>the cron is set to start at the top of the hour
14:39:28  <swaagie>haha
14:39:29  <ggoodman>those weren't 'zombies'
14:39:36  <nmanousos>21 minutes
14:39:49  <swaagie>nmanousos: ah ok
14:39:52  <nmanousos>cool to wait?
14:39:55  <swaagie>sure
14:39:56  <nmanousos>so i dont have to deploy again
14:39:58  <swaagie>np
14:40:01  <nmanousos>thanks
14:40:32  <nmanousos>thank you for looking into this!
14:41:15  * mokesquit (Remote host closed the connection)
14:42:06  <swaagie>nmanousos: np :) your welcome thank Sly for checking our new part of our brain
14:42:18  <swaagie>was on devops duty anyways
14:42:24  <nmanousos>thx Sly!
14:44:29  * mokesjoined
14:44:40  * bzoojoined
14:47:24  * Arunodajoined
14:47:33  * mdedetrichquit (Quit: Computer has gone to sleep.)
14:48:06  * ionella_quit (Remote host closed the connection)
14:48:12  * calwebquit (Quit: Leaving.)
14:50:41  * calwebjoined
14:52:42  * InconceivableBjoined
14:55:51  * thealanwattsriotjoined
14:56:30  * thealanwattsriotquit (Client Quit)
14:57:52  * jmar777quit (Read error: Connection reset by peer)
14:58:07  * rosskjoined
14:58:12  * calwebquit (Quit: Leaving.)
14:58:18  * jmar777joined
15:03:29  * cronopiojoined
15:06:24  * alxjoined
15:06:48  * sreeixquit (Quit: sreeix)
15:07:45  * kevino80quit (Remote host closed the connection)
15:09:20  * kevino80joined
15:09:26  <nmanousos>Sly, swaagie: that was it! it's fixed now - thanks again!
15:11:13  * sandfoxjoined
15:11:24  <swaagie>nmanousos: np glad we could help
15:11:34  * nmanousosquit (Quit: Page closed)
15:15:19  * TooTallNatejoined
15:16:05  * calwebjoined
15:18:03  * andreypoppjoined
15:19:24  * bzooquit (Remote host closed the connection)
15:19:38  * TooTallNatequit (Ping timeout: 240 seconds)
15:19:57  * bzoojoined
15:20:25  * mokesquit (Remote host closed the connection)
15:21:24  * andreypoppquit (Client Quit)
15:21:45  * mokesjoined
15:21:48  * andreypoppjoined
15:22:14  * paralleljoined
15:23:45  * calwebquit (Quit: Leaving.)
15:24:56  * bzooquit (Ping timeout: 268 seconds)
15:25:25  * armiquit (Ping timeout: 250 seconds)
15:25:46  * user123joined
15:25:54  <user123>hi
15:25:59  <user123>anyone available to answer questions?
15:28:27  * pjbrinckquit (Ping timeout: 250 seconds)
15:29:05  * ven2019joined
15:29:16  * ven2019quit (Client Quit)
15:34:06  * andreypoppquit (Quit: andreypopp)
15:34:31  * user123quit (Ping timeout: 250 seconds)
15:36:02  * cronopioquit (Quit: Bye)
15:36:11  * andreypoppjoined
15:36:30  * cronopiojoined
15:40:11  * waygeejoined
15:44:26  * tonistquit (Quit: tonist)
15:45:04  * waygeequit (Quit: waygee)
15:45:40  * tylerstalderjoined
15:47:03  * ionellajoined
15:47:21  * c4miloquit (Remote host closed the connection)
15:52:58  * jafarjoined
15:53:12  <jafar>hello
15:53:22  <jafar>are the servers down
15:55:52  * calwebjoined
15:56:15  * bzoojoined
15:57:17  * frenchtoastquit (Ping timeout: 256 seconds)
15:57:53  * sol_invictusquit (Remote host closed the connection)
15:58:57  * c4milojoined
15:59:10  * frenchtoastjoined
16:00:17  * ionellaquit (Remote host closed the connection)
16:00:35  * joshonthewebjoined
16:00:50  * daviddiasjoined
16:01:07  * x_orjoined
16:02:31  * thealanwattsriotjoined
16:04:08  * sol_invictusjoined
16:06:35  * andreypoppquit (Quit: andreypopp)
16:08:56  * andreypoppjoined
16:09:11  * secobarbitalquit (Ping timeout: 250 seconds)
16:11:49  * Arunodaquit (Remote host closed the connection)
16:11:59  * sandfoxquit (Quit: sandfox)
16:19:35  * jafarquit (Ping timeout: 250 seconds)
16:19:52  * joshonthewebquit (Quit: Computer has gone to sleep.)
16:20:55  * johnmartyquit (Quit: Leaving.)
16:28:23  * mokesquit (Remote host closed the connection)
16:29:32  * mokesjoined
16:31:33  * joeybakerjoined
16:32:10  * PaperWingsquit (Ping timeout: 256 seconds)
16:32:18  * andreypoppquit (Quit: andreypopp)
16:34:09  * calwebquit (Quit: Leaving.)
16:34:33  * Fishrock123joined
16:34:33  * mokesquit (Remote host closed the connection)
16:34:38  * brianruejoined
16:35:38  * sol_invictusquit (Remote host closed the connection)
16:36:30  * diogogmtjoined
16:37:50  * mokesjoined
16:38:08  * ejeklintquit (Quit: ejeklint)
16:40:23  * sol_invictusjoined
16:40:47  * thealanwattsriotquit (Quit: Computer has gone to sleep.)
16:42:59  * andreypoppjoined
16:44:23  * mokesquit (Remote host closed the connection)
16:46:56  * mokes_joined
16:49:54  * frenchtoastquit (Ping timeout: 276 seconds)
16:51:51  * sandfoxjoined
16:56:31  * daviddiasquit (Remote host closed the connection)
16:57:08  * daviddiasjoined
17:01:54  * daviddiasquit (Ping timeout: 264 seconds)
17:02:27  * daviddiasjoined
17:03:11  * mokes_quit (Remote host closed the connection)
17:06:11  * chjjquit (Quit: leaving)
17:08:27  * sicularsjoined
17:09:24  * calwebjoined
17:09:48  * joshonthewebjoined
17:10:43  * ionellajoined
17:11:11  * tonistjoined
17:15:42  * ionellaquit (Ping timeout: 264 seconds)
17:17:11  * TooTallNatejoined
17:19:24  * sol_invictusquit (Read error: Connection reset by peer)
17:19:44  * mokesjoined
17:19:56  * sol_invictusjoined
17:21:01  * sandfoxquit (Quit: sandfox)
17:25:09  * parallelquit (Remote host closed the connection)
17:28:17  * Fishrock123quit (Remote host closed the connection)
17:28:53  * Fishrock123joined
17:29:01  * paralleljoined
17:29:21  * mokesquit (Remote host closed the connection)
17:32:55  * Fishrock123quit (Ping timeout: 245 seconds)
17:37:31  * alxquit (Remote host closed the connection)
17:38:46  * daviddia_joined
17:40:21  * alxjoined
17:40:46  * thealanwattsriotjoined
17:40:51  * daviddiasquit (Ping timeout: 245 seconds)
17:44:13  * Fishrock123joined
17:48:33  * joeybakerquit (Quit: Computer has gone to sleep.)
17:50:32  * sreeixjoined
17:50:39  * joeybakerjoined
17:51:52  * joeybakerquit (Client Quit)
17:52:59  * johnmartyjoined
17:53:15  * joeybakerjoined
17:55:00  * michaeldeoljoined
17:55:43  * frenchtoastjoined
17:58:38  * Tarang_joined
17:59:33  * mokesjoined
18:00:15  * leichtgewichtquit (Remote host closed the connection)
18:00:20  * frenchtoastquit (Ping timeout: 268 seconds)
18:03:21  * alxquit (Remote host closed the connection)
18:04:48  * Tarangquit (Ping timeout: 240 seconds)
18:04:49  * svnltoquit (Ping timeout: 240 seconds)
18:05:14  * Tarang_changed nick to Tarang
18:10:23  * johnmartyquit (Quit: Leaving.)
18:12:29  * mattangejoined
18:12:29  <mattange>Hi
18:13:07  <mattange>is someone else experiencing problems in deployments... it says "No free servers available" after having tried to start the app
18:13:14  * svnltojoined
18:15:15  <mattange>anyone else experiencing this problem? also seems the same when trying to restart a previous version of the App, which was working in full
18:15:22  <Sly>mattange: Give me one minute.
18:16:00  <mattange>thanks
18:16:12  * Hebojoined
18:16:35  <Sly>mattange: try again for me.
18:17:59  * jgablequit (Quit: Computer has gone to sleep.)
18:18:37  <mattange>ok - seems ok on old version now. Pls let me try to activate new one now.
18:18:40  <mattange>just making sure
18:19:34  <mattange>perfect - seems working now
18:19:39  <mattange>thanks for quick help
18:19:46  <Sly>np. :)
18:19:47  * ionellajoined
18:20:10  * frenchtoastjoined
18:20:32  * ionellaquit (Remote host closed the connection)
18:26:55  * frenchtoastquit (Ping timeout: 264 seconds)
18:31:19  * sol_invictusquit (Remote host closed the connection)
18:33:33  * joeybakerquit (Quit: Computer has gone to sleep.)
18:33:36  * alx_joined
18:34:15  * julianduquejoined
18:34:18  * skunkwerksjoined
18:34:40  * joeybakerjoined
18:34:53  * joeybakerquit (Client Quit)
18:37:51  * jgablejoined
18:38:00  * parallelquit (Remote host closed the connection)
18:38:43  * paralleljoined
18:41:22  * coen-hydejoined
18:43:34  <coen-hyde>hey guys i'm having trouble deploying. socket hangup
18:46:07  * pala2joined
18:46:20  * coen-hydequit (Quit: coen-hyde)
18:46:30  * joeybakerjoined
18:46:38  * parallelquit (Read error: Connection reset by peer)
18:47:00  * paralleljoined
18:47:03  * joeybakerquit (Client Quit)
18:49:05  * benjaminbenben_joined
18:49:26  <Fishrock123>Did you guys just deploy a patch for something that doesn't allow a deploy when a module has more than one repo field? Because it's giving me issues. :/
18:50:09  <Fishrock123>Gist: https://gist.github.com/Fishrock123/4cca059d559c8e67d24c
18:50:19  <Fishrock123>(it just hangs there)
18:50:55  <Sly>Fishrock123: no, that's an NPM thing.
18:50:58  <Sly>Not anything to do with us
18:51:35  * parallelquit (Remote host closed the connection)
18:53:02  * spoluquit (Ping timeout: 264 seconds)
18:54:45  * defunctzombie_zzchanged nick to defunctzombie
18:55:07  <Fishrock123>Oops, turns out it was a very long socket hang up. cc Sly
19:00:35  * calwebquit (Quit: Leaving.)
19:03:29  * coen-hydejoined
19:03:53  * calwebjoined
19:09:17  * benjaminbenben_quit (Quit: benjaminbenben_)
19:11:49  * paultmanquit (Quit: Connection closed for inactivity)
19:15:39  * CKjoined
19:16:08  <CK>Hello
19:16:18  * martin_joined
19:16:21  * CKquit (Client Quit)
19:17:36  * CK95014joined
19:17:51  <CK95014>Hi There...
19:18:02  * mokesquit (Remote host closed the connection)
19:18:16  * coen-hydequit (Quit: coen-hyde)
19:19:12  * mokesjoined
19:23:03  * paralleljoined
19:25:26  * calwebquit (Quit: Leaving.)
19:25:30  * joeybakerjoined
19:26:19  <martin_>Hi everyone
19:26:34  * Heboquit
19:26:40  * tobie_quit (Quit: tobie_)
19:27:54  * tobie_joined
19:28:55  * jbprosjoined
19:29:09  <CK95014>Not sure how this works!! Do I just post my request and wait on answers from the folks on the list to my right...
19:36:18  * daviddia_quit (Remote host closed the connection)
19:36:47  * jbprosquit (Quit: jbpros)
19:36:52  <mmalecki>martin_: hey
19:36:53  * daviddiasjoined
19:38:00  * therealkoopaquit (Remote host closed the connection)
19:38:36  * parallelquit (Remote host closed the connection)
19:41:16  * daviddiasquit (Ping timeout: 245 seconds)
19:43:01  <martin_>Hi mmalecki, how are you doing>
19:44:30  * Hebojoined
19:47:11  <mmalecki>martin_: good! how are you?
19:47:31  * daviddiasjoined
19:47:33  * skunkwerksquit (Quit: how now brown cow?)
19:48:14  <martin_>Excellent. Living the good life here.
19:48:25  <martin_>How is your visa situation coming, any updates there?
19:51:00  <mmalecki>martin_: it's a huge legal pain in the ass, as usual
19:51:00  * brianruequit (Remote host closed the connection)
19:51:35  * brianruejoined
19:52:23  <martin_>I know.
19:53:16  <martin_>Friend of mine here is working on his O-1, although he is an actor, which is presumable easier once you have SAG-AFTRA on your side. Let me know if I can be of any help, I have done this twice ;-)
19:55:08  <mmalecki>heh, that's the same type I'm trying to get. thanks for your offer, I appreciate it! :-)
19:55:48  <martin_>You should talk to Peter Bell, he got an o-1 a year ago in our line of business
19:55:50  * brianruequit (Ping timeout: 245 seconds)
19:56:01  <martin_>I think you might know him
19:56:13  <martin_>he was/is a nodejitsu customer
19:56:55  <martin_>otherwise just msg me on Facebook (martinw) and I will make the connection
20:00:09  * therealkoopajoined
20:02:30  * thealanwattsriotquit (Ping timeout: 245 seconds)
20:03:21  * happycloudjoined
20:04:11  <happycloud>Morning. Having DB connection issue over the weekend to mongolab. Email from NJ says it's crash looping - log suggest a mongolab issue. Mongolab says they see nothing. https://gist.github.com/cyberwombat/1425e2e935db7627b7a4
20:05:24  * thealanwattsriotjoined
20:05:28  * thealanwattsriotquit (Max SendQ exceeded)
20:06:09  * haigotjoined
20:06:14  <haigot>Hi anyone around for a quick question?
20:06:14  * thealanwattsriotjoined
20:06:43  <swaagie>happycloud: hey there can you connect to that dbase instance from localhost?
20:06:49  <swaagie>haigot: hey there, shoot
20:07:19  <haigot>So i need to uplaod images, there is probably no way to store them on my drone right?
20:07:32  <haigot>ill need to store in a database or externally?
20:07:39  <swaagie>haigot: well you can store them there temporary, but as soon as you redeploy they will be lost
20:08:18  <martin_>haigot: normally people store it on amazon s3 or a similar store, databases, including mongodb, are not recommended
20:08:28  <swaagie>^ thx martin_
20:08:32  <haigot>That's what I figured
20:08:47  <haigot>why would you not recommend mngo?
20:08:48  <happycloud>swaagie no - I have a CLI line I use to backup/dl the db - direct connection - was not able to use that either. But I emailed mongolab and they said they see nothing. But it happened on Sat and Sun - down for maybe 10-15 min before the restart took
20:09:43  <swaagie>happycloud: hmm I your cli creates a direct connection that would exclude any of our architecture
20:09:51  <swaagie>I/if*
20:10:21  * Heboquit
20:11:44  <martin_>It's not really there intended use case. S3 gives you better options, both price wise and from a convenience perspective, not to mention the external tools that integrate well with it (like filepicker.io, transloadit.com etc).
20:11:47  <swaagie>happycloud: also since it worked before i'm assuming credentials etc are correct so it would be a pure connection problem, I can't say with certainty if thats on our side or mongolab side of course
20:12:01  * daviddiasquit (Remote host closed the connection)
20:12:17  <swaagie>happycloud: does it still affect you?
20:12:28  * daviddiasjoined
20:12:46  * joeybakerquit (Quit: Computer has gone to sleep.)
20:13:06  * michaeldeolquit (Remote host closed the connection)
20:13:14  <happycloud>haigot - I just went through the pain of upload - had some memory issues uploading to my small drone on NJ (personal) and ended up using a direct to S3 upload - a bit of a pain to setup as you need to generate a policy but def doable and works great
20:13:14  <happycloud>swaagie so just hound mongolab?
20:13:20  * daviddia_joined
20:14:22  <happycloud>it's ok right now - just on sat and again in sun - 15min each time of me trying to restart. Not so concerned about a db down for 10min but the prob is that NJ will not restart so my downtime can be hours if I am not around
20:16:23  <swaagie>happycloud: you might want to capture that error in any case and just prevent stuff from happening if the connection is gone, obviously this shouldn't happen at all, but I can't really vouch for our 3rd-party affliates
20:16:47  * daviddiasquit (Ping timeout: 240 seconds)
20:17:22  <swaagie>and im afraid that on the current issue we wont be having much more logs than what your seeing atm, your only hope would that mongolab knows about some issue that appeared in their architecture
20:17:39  <happycloud>swaagie you mean handle the error and just show a 500 error page type of thing instead of crashing?
20:17:53  <swaagie>happycloud: what is your username/appname, so I can check the logs just in case
20:17:56  <happycloud>I emailed ML again- we'll see
20:18:02  <happycloud>gonegreen/gonegreen
20:18:39  <swaagie>happycloud: something like that, I dont know how you use your db ofc, connect logic, how often stuff is written and when etc.
20:19:04  * Hebojoined
20:19:47  * thealanwattsriotquit (Ping timeout: 240 seconds)
20:20:19  <swaagie>better catch connection failure as it is bound to happen, the DNS could have issues, joyent, mongolab, some other middleman company etc
20:20:28  <haigot>Thanks!
20:21:31  * joeybakerjoined
20:23:07  * mattangequit (Ping timeout: 250 seconds)
20:23:08  * thealanwattsriotjoined
20:27:49  * brianruejoined
20:27:52  * x_orquit (Read error: No route to host)
20:28:29  * sreeixquit (Quit: sreeix)
20:29:07  <swaagie>happycloud: seeing some other errors as well, related to mongo that is
20:29:29  <swaagie>Error: Error setting TTL index on collection : sessions <MongoError: not master and slaveOk=false>
20:29:30  <happycloud>swaagie yes?
20:29:45  * sreeixjoined
20:29:45  <happycloud>yes have had that a bit - sessions dont start
20:29:54  <happycloud>not sure what it is
20:29:58  * benjaminbenbenquit (Quit: benjaminbenben)
20:30:05  * mokesquit (Remote host closed the connection)
20:30:41  * mokesjoined
20:31:57  * chjjjoined
20:35:00  * tobie_quit (Quit: tobie_)
20:35:30  * mokesquit (Ping timeout: 264 seconds)
20:36:45  * sicularsquit (Quit: siculars)
20:39:03  * paralleljoined
20:42:09  * Heboquit
20:42:41  * tylerstalderquit (Quit: Computer has gone to sleep.)
20:42:45  * daviddia_quit (Remote host closed the connection)
20:42:57  * michaeldeoljoined
20:43:17  * martin_quit (Quit: martin_)
20:43:21  * daviddiasjoined
20:43:45  * parallelquit (Ping timeout: 268 seconds)
20:44:00  * Hebojoined
20:45:46  * sreeixquit (Quit: sreeix)
20:47:42  * mokesjoined
20:47:47  * sandfoxjoined
20:47:52  * daviddiasquit (Ping timeout: 264 seconds)
20:50:30  * gustonegrojoined
20:51:00  <gustonegro>hello, is it possible to write to /tmp (or some other dir) in nodejitsu?
20:52:14  * tobie_joined
20:53:38  * daviddiasjoined
20:53:46  <julianduque>gustonegro: you can write on dir on your path __dirname + '/tmp'
20:54:44  <gustonegro>julianduque: aha....but that won't be collected later, will it? I need to delete it myself?
20:55:25  <julianduque>gustonegro: if you deploy again the folder will be gone, persistence is temporary on nodejitsu
20:56:38  <gustonegro>julianduque: do I need to worry about how much I write to disk?
20:57:05  <julianduque>gustonegro: up to 3GB
20:57:59  <jesusabdullah>julianduque: Just to make sure: That message you just replied to that was forwarded from me, did it get sent to the right dude? Or did it just bounce back to me?
20:58:08  <jesusabdullah>julianduque: I can forward but, yeah, u noe
20:59:03  <julianduque>jesusabdullah: I cc'd him
21:02:21  * happycloudpart
21:08:51  <gustonegro>julianduque: thank you.
21:10:32  * ggoodmanquit (Quit: Page closed)
21:11:52  * protometajoined
21:11:54  <jesusabdullah>julianduque: fantastic, I'll delete this then :)
21:13:24  <julianduque>:)
21:14:41  <jesusabdullah>yeah that was one of the lamer emails I've received in my time XD
21:15:42  * mokesquit (Remote host closed the connection)
21:16:04  * andreypoppquit (Quit: andreypopp)
21:16:25  <julianduque>lol
21:18:02  <protometa>Hey nodejisu sensei...
21:18:58  <protometa>I have some questions about file uploads.
21:19:34  <julianduque>feel free to ask
21:20:31  * thealanwattsriotquit (Quit: Computer has gone to sleep.)
21:21:04  <protometa>Is it okay to populate directories with uploads on nodejitsu? Are there any limitations or dangers to be aware of?
21:21:35  <julianduque>protometa: it's ok, up to 3GB `temporary space`
21:21:49  <julianduque>protometa: temporary means that files aren't persisted across deploys
21:22:17  <protometa>Ah that makes sense.
21:24:57  <protometa>What are the options for persistent file uploads?
21:25:10  * mokesjoined
21:25:16  <protometa>GridFS...
21:25:39  <protometa>I've also seen this pkgcloud thing...
21:25:49  <kenperkins>what about pkgcloud? :)
21:25:56  <julianduque>protometa: you can use s3, cloudfiles with pkgcloud
21:26:27  * joeybakerquit (Quit: Computer has gone to sleep.)
21:27:53  <protometa>Can pkgcloud do generic ftp stuff?
21:28:13  <kenperkins>no
21:28:24  <kenperkins>pkgcloud is a multi-provider cloud library
21:28:40  * Samuel_Roldan_joined
21:28:40  <kenperkins>cloud storage, cloud compute, and limited other services
21:31:35  * frenchtoastjoined
21:32:47  * Samuel_Roldanquit (Ping timeout: 260 seconds)
21:32:48  * Samuel_Roldan_changed nick to Samuel_Roldan
21:37:48  * tonistquit (Quit: tonist)
21:38:45  * jgablequit (Quit: Computer has gone to sleep.)
21:38:55  * jmar777quit (Remote host closed the connection)
21:42:14  * frenchto1stjoined
21:42:55  * frenchtoastquit (Ping timeout: 245 seconds)
21:43:18  * jcrugzz_joined
21:43:30  * martin_joined
21:46:07  * jcrugzzquit (Ping timeout: 264 seconds)
21:46:17  * tobie_quit (Quit: tobie_)
21:47:26  <protometa>OK, I'm going to try out pkgcloud. Thanks!
21:47:58  <kenperkins>protometa: don't hestitate to ask questions
21:49:02  <protometa>OK
21:49:12  <julianduque>kenperkins: o/
21:49:20  <kenperkins>o/
21:51:32  * tobie_joined
21:51:33  * jcrugzz_changed nick to jcrugzz
21:52:15  <protometa>I'll try out pkgcloud for my DB client as well...
21:54:44  * thealanwattsriotjoined
21:56:41  * tobie_quit (Quit: tobie_)
21:56:54  * joeybakerjoined
21:57:59  * joeybakerquit (Client Quit)
22:01:40  * c4miloquit (Remote host closed the connection)
22:02:26  * Samuel_Roldanquit (Quit: Samuel_Roldan)
22:03:12  * cronopioquit (Ping timeout: 276 seconds)
22:03:14  * mokesquit (Remote host closed the connection)
22:04:37  * c4milojoined
22:08:09  * kevino80quit (Remote host closed the connection)
22:14:33  * andreypoppjoined
22:22:21  * Fishrock123quit (Remote host closed the connection)
22:22:27  * thealanwattsriotquit (Quit: Computer has gone to sleep.)
22:22:28  * paralleljoined
22:23:53  * parallel_joined
22:23:59  * parallelquit (Read error: Connection reset by peer)
22:24:23  <protometa>Does the pkgcloud client for storage do any CRUD or does it just manage databases and accounts?
22:24:38  <kenperkins>it just manages the database provider
22:24:41  <kenperkins>not the databse itself
22:26:56  * andreypoppquit (Quit: andreypopp)
22:27:49  <protometa>So for a given mongo DBaaS it can give me the DB url to work with?
22:28:59  * calwebjoined
22:30:02  <julianduque>protometa: but for create databases and users and stuff, provider stuff, you are looking something like `mongoose` for mongodb
22:33:43  * mokesjoined
22:35:24  <protometa>Ok I see.
22:37:42  * calwebquit (Quit: Leaving.)
22:38:12  * paralleljoined
22:38:36  * parallel_quit (Read error: Connection reset by peer)
22:39:20  * Fishrock123joined
22:40:00  * mokesquit (Ping timeout: 245 seconds)
22:40:46  <protometa>So pgkcloud I will allow me to manage databases with the DBaaS and then give me the info to connect to them with Mongoose or whatever.
22:40:58  <kenperkins>exactly
22:42:50  <protometa>Cool!
22:46:10  * Heboquit
22:46:40  * alx_quit (Remote host closed the connection)
22:49:34  * jgablejoined
22:53:03  * Samuel_Roldanjoined
22:53:48  * Fishrock123quit (Remote host closed the connection)
22:55:16  * jgablequit (Quit: Textual IRC Client: www.textualapp.com)
22:56:53  * Fishrock123joined
22:57:44  * Hebojoined
22:58:13  * andreypoppjoined
23:04:18  * jcrugzzquit (Ping timeout: 264 seconds)
23:06:07  * andreypoppquit (Ping timeout: 260 seconds)
23:06:52  * andreypoppjoined
23:08:26  * jmar777joined
23:13:43  <rossk>protometa: pkgcloud +1
23:14:54  <mmalecki>rossk: heyy! what's up?
23:15:00  <rossk>hey mmalecki
23:15:16  <rossk>trying to clean my desk off -- getting married next week
23:15:27  <mmalecki>rossk: congrats!
23:15:32  <rossk>thanks lookign forward to it
23:16:10  <rossk>FYI, published prelim version of pkgcloud-cli
23:16:19  <rossk>missing a whole pile of features
23:16:28  <mmalecki>ohhh! that's awesome. where can I contribute?
23:16:37  <rossk>https://github.com/rosskukulinski/pkgcloud-cli
23:16:54  <mmalecki>I'm actually starting a small thing on a side and not using baton becomes very hard
23:17:02  <rossk>ha!
23:17:16  <rossk>it does the bare-min of what I need now
23:17:35  <rossk>its also in npm too
23:17:41  <rossk>npm i -g pkgcloud-cli
23:17:59  <rossk>feedback/issues/contribs appreciated
23:18:04  <rossk>hate can go to /dev/null
23:18:08  * frenchto1stquit (Remote host closed the connection)
23:18:26  <julianduque>rossk: great
23:18:45  <rossk>i don't work with any of the db providers
23:18:58  <rossk>so hopefully someone can help with that (or if no-one needs it... f-it)
23:19:09  <rossk>same with Files
23:19:14  <rossk>thanks julianduque
23:19:16  <mmalecki>rossk: I'll contribute features
23:19:37  <rossk>the thing that I think will make it really helpful (and I've built it towards this)
23:19:46  <rossk>is supporting multiple providers
23:19:58  <rossk>so your config file can specify several cloud providers
23:20:02  <rossk>and see the stats for all of them
23:20:28  <mmalecki>rossk: that's awesome
23:20:34  <rossk>i'm still hacking with multi-pkgcloud (https://github.com/rosskukulinski/multi-pkgcloud)
23:20:38  <mmalecki>kinda like baton, except on fs
23:20:40  <rossk>haven't pushed yet
23:20:47  <rossk>exactly
23:20:55  <rossk>and without groups, etc at this point
23:21:12  <rossk>and it'll eventually do name-space creation
23:21:45  <rossk>so like -- pkgcloud compute create server --name my-db-server --image db-server --region ORD
23:22:00  <rossk>would do a lookup of the image name
23:22:12  <rossk>so you don't need to find the damn image id for that region
23:22:25  <rossk>as long as you use consistent image naming across your providers
23:22:54  <rossk>I have most of that, but it's not quite ready for a push
23:23:04  <rossk>i'll get back to it in september post-wedding
23:23:16  * InconceivableBquit (Quit: Computer has gone to sleep.)
23:23:24  <rossk>and i'll have to do a blog post at some point
23:24:11  <mmalecki>rossk: yo, want to give me maintainer access? I could do some work 'till you're back
23:28:47  <rossk>mmalecki: (please don't be offended) but I think I'm going to hold onto collaborator status until chatting more about long-term goals and that sort of thing
23:31:58  <rossk>but until the PRs are more than welcome
23:32:19  * Arunodajoined
23:32:34  <rossk>if you'd like to chat sometime this week I'll be available on skype
23:34:22  * mokesjoined
23:34:26  * jcrugzzjoined
23:35:07  * joeybakerjoined
23:39:06  * mokesquit (Ping timeout: 264 seconds)
23:39:58  * c4miloquit (Remote host closed the connection)
23:41:17  * c4milojoined
23:41:19  * marciopugajoined
23:41:37  <marciopuga>hello
23:41:56  <julianduque>marciopuga: Hello!
23:42:24  <marciopuga>hi julianduque
23:42:39  <marciopuga>I'm having problems to restart the lasvegas-now drone
23:43:37  <julianduque>marciopuga: let me check, what is your username?
23:44:31  <marciopuga>marciopuga
23:45:56  * pala2quit (Quit: Leaving.)
23:51:04  * andreypoppquit (Quit: andreypopp)
23:53:21  * marciopugaquit (Ping timeout: 245 seconds)
23:59:42  * jmar777quit (Remote host closed the connection)