( filed by marak )

I'd like to add something like:

 winston.warn('There is a new version of jitsu available. Please run npm update jitsu');

When users are running jitsu and a new version of it is available on npm.

I'm not sure the best way to achieve this. @indexzero any thoughts?

I am unable to deploy a basic helloworld application using jitsu deploy with most recent version of jitsu

I receive sporadic errors of the following two varieties:

Nodejitsu Error (500): Internal Server Error
https://gist.github.com/9d212b20d7e44c061147

Error: ECONNREFUSED, Connection refused
https://gist.github.com/44f535a61651eafe1c35

@indexzero -

It occurs to me we might have had a bit of a regression in that users cannot confirm their accounts from the command line anymore?

Since we require the users to go through the process of authenticating before they can use jitsu ( or even access it's help ), there is no way the user will be able to make it to the screen where they enter in their confirmation id?

This also seems related to this ticket: #14

We should create better MarkDown documentation and then split it into sections that http://rtomayko.github.com/ronn/ can easily consume to create man pages.

We can then use these MD files to help auto-generate the ReadME.md file

very minor develop.nodejitsu.com issue in Billing information screen - the number of **** in the Password and Confirm Password are different.

Just a polish type of thing.

We should make it easier for users to reset their passwords if they have forgotten them.

1. Add .info('reset password instructions') when bad login
2. Prompt "would you like to reset your password" after 3 failed logins
3. Update help section

Thanks @DTrejo!

Was a bit confusing b/c I expected it to say that it successfully saved my creds, or something like that (after looking again, I do see that it says it authenticated, so that's good).

  172-30-6-187:artistpaper david$ jitsu
info:   Welcome to Nodejitsu
info:   It worked if it ends with Nodejitsu ok
info:   No user has been setup on this machine
prompt: Username: dtrejo
prompt: Password: 
info:   Authenticated as dtrejo
info:   Executing command 
error:  Error running command 
error:  Resource is required, try: jitsu help
info:   Nodejitsu not ok

@indexzero

How would you feel about having the body the of the request get dumped to the terminal if a 500 is returned? Possibly truncate it if its too long?

Right now we just get a generic message printed which doesn't help much.

Users should be able to perform the entire signup process entirely from the command line via jitsu signup. Right now the signup process is hard to find.

Visual bug:

nico@pizza:~/nodejitsu/jitsu$ bin/jitsu users forgot marak
info: Welcome to Nodejitsu
info: It worked if it ends with Nodejitsu ok
info: Executing command users forgot marak
info: Request password reset for :marak //<-- the space is on the wrong side of the :
info: Check your email for password reset link
info: Nodejitsu ok

if there is a bug with require-analyzer it prevents deployment to nodejitsu.

for example: nodejitsu/require-analyzer#4

It appears that the package.json write is sometimes triggered twice when deploying apps.

To reproduce:

1. clone marak's hellonode application
2. (you may have to deploy once before deleting the package.json)
3. delete the package.json
4. jitsu deploy
5. read screen output ( package is written twice )

This is a low priority issue.

Currently, colors are applied to column headers...
https://github.com/nodejitsu/jitsu/blob/master/lib/jitsu/log.js#L68

However, there isn't a lot of meaning behind the application of the color.
As an alternative to passing in an arbitrary array of colors, I would prefer to pass in an object-lit with keywords that are corollary to potential values. For instance { 'stopped': 'red', 'started': 'green' }.

I think this makes the use of colors more meaningful. thoughts?

Currently being discussed internally, will post progress here.

Related Tickets:
#11
#12
#13

prior to this I did

npm uninstall jitsu
npm cache clean jitsu
git clone this repo
cd this repo
npm link

Then I tried this:

    DTrejo:artistpaper david$ jitsu create
    info:   Welcome to Nodejitsu
    info:   It worked if it ends with Nodejitsu ok
    info:   Executing command create
    info:   Authenticated as dtrejo
    help:   In order to create an application we'll need a unique subdomain
    help:   You're application will then become accessible at:  http://yourdomain.nodejitsu.com
    prompt: Subdomain: dtrejo

    /Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:187
        Object.keys(results).forEach(function (key) {
               ^
    TypeError: Object.keys called on non-object
        at Function.keys (native)
        at /Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:187:12
        at /Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:107:34
        at /Users/david/local/lib/node/.npm/async/0.1.8/package/lib/async.js:126:25
        at /Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:102:7
        at /Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:134:5
        at ReadStream.data (/Dropbox/dev/forks/jitsu/lib/jitsu/prompt.js:214:7)
        at ReadStream.emit (events.js:64:17)
        at ReadStream._onReadable (net.js:667:31)
        at IOWatcher.onReadable [as callback] (net.js:177:10)
    DTrejo:artistpaper david$

When trying to start an application using:

 jitsu start myapp

We are seeing cases where the application does not start, but jitsu reports back to the application has started. This is confusing because jitsu is not reporting any errors, and the user is getting a confirmation message that the application started when no application is running.

We were using test application: "dominictarr/thispackage"

I'm having a strange problem with jitsu.

I'm gettings some apps which won't update. they seem to get stuck at a particular version.

this is the pattern I've found:

I deploy and it gives be a 500 error. if I deploy again, it says 'ok'.

now if I jitsu apps view App I get a message like this:

data:   {
data:       active: {
data:           id: '0.0.0-7',
data:           ctime: 1305920004638,
data:           md5: '49867d677cdd0c6d3bdf39ba02e9bf5c',
data:           filename: 'dominictarr-SweetAs2-0.0.0-7.tgz'
data:       },
data:       name: 'SweetAs2',
data:       scripts: { start: 'server.js' },
data:       snapshots: [
data:           { id: '0.0.0-2', created: '2011/5/20 12:26:33' },
data:           { id: '0.0.0-3', created: '2011/5/20 12:32:13' },
data:           { id: '0.0.0-4', created: '2011/5/20 12:32:27' },
data:           { id: '0.0.0-5', created: '2011/5/20 12:32:41' },
data:           { id: '0.0.0-6', created: '2011/5/20 12:33:16' },
data:           { id: '0.0.0-7', created: '2011/5/20 12:33:24' }
data:       ],
data:       state: 'started',
data:       subdomain: 'sweetas2',
data:       user: 'dominictarr',
data:       version: '0.0.0-7'
data:   }

looks reasonable, expect it doesn't agree with jitsu apps list:

info:   Listing apps
data:   name        state   subdomain   start     latest                              
data:   SweetAs     stopped sweetas     server.js dominictarr-SweetAs-0.0.0-14.tgz    
data:   SweetAs2    started sweetas2    server.js dominictarr-SweetAs2-0.0.0-2.tgz    
data:   crm         stopped crm         app.js    dominictarr-crm-0.0.0-1.tgz         
data:   hello-world started hello-world server.js dominictarr-hello-world-0.0.0-1.tgz 
data:   hi-express  stopped hi-express  app.js    dominictarr-hi-express-0.0.0-1.tgz  
info:   Nodejitsu ok

Note that view reports that SweetAs 2 is active on 0.0.0-7 but list says it's at version 0.0.0-2 (which seems to be what is happening, because it does not change update)

nt

It seems that the package.json get's recreated after checking for deps, even if no deps are found.

It also appears related to this ticket: #19

currently .jitsuconf is loaded immediately from ~/.jitsuconf it would be much better to search through parent directories before getting to home.

this would allow local configurations.
i.e. using different settings/auth for a testing account, or for nodejitsu users to do work for seperate clients in seperate accounts.

There should be a better message here. It's not an error. It's a warning

jitsu config delete port
info:   Welcome to Nodejitsu
info:   It worked if it ends with Nodejitsu ok
info:   Executing command config delete port
error:  No configuration value for port
help:   
help:   Usage:
help:   Deletes the specified  in the jitsu configuration
help:   
help:   jitsu config delete 
help:   
error:  Error running command config delete port
info:   Nodejitsu not ok

The contextual help inside jitsu could use some improvement. The built in menu system has also become slightly cluttered / is missing some commands.

https://github.com/nodejitsu/jitsu/blob/master/lib/jitsu/package.js#L358

$ jitsu deploy                                                                                           [/Users/jxck/Dropbox/src/javascript/node/nodejitu/test]
info:   Welcome to Nodejitsu
info:   It worked if it ends with Nodejitsu ok
info:   Executing command deploy
info:   Authenticated as Jxck
info:   Analyzing your application dependencies in server.js

/Users/jxck/.nvm/v0.4.7/lib/node/.npm/jitsu/0.3.3/package/lib/jitsu/package.js:358
  return old || update 
  ^
ReferenceError: update is not defined
    at Object.updateTarball (/Users/jxck/.nvm/v0.4.7/lib/node/.npm/jitsu/0.3.3/package/lib/jitsu/package.js:358:3)
    at updateSnapshot (/Users/jxck/.nvm/v0.4.7/lib/node/.npm/jitsu/0.3.3/package/lib/jitsu/commands/apps.js:69:19)
    at /Users/jxck/.nvm/v0.4.7/lib/node/.npm/jitsu/0.3.3/package/lib/jitsu/package.js:185:74
    at /Users/jxck/.nvm/v0.4.7/lib/node/.npm/jitsu/0.3.3/package/lib/jitsu/package.js:259:5
    at /Users/jxck/.nvm/v0.4.7/lib/node/.npm/require-analyzer/0.1.3/package/lib/require-analyzer.js:170:16
    at cb (/Users/jxck/.nvm/v0.4.7/lib/node/.npm/npm/0.3.18/package/lib/ls.js:58:31)
    at Object.<anonymous> (/Users/jxck/.nvm/v0.4.7/lib/node/.npm/require-analyzer/0.1.3/package/lib/require-analyzer.js:139:5)
    at /Users/jxck/.nvm/v0.4.7/lib/node/.npm/npm/0.3.18/package/lib/ls.js:60:12
    at /Users/jxck/.nvm/v0.4.7/lib/node/.npm/npm/0.3.18/package/lib/ls.js:109:12

1. Use http://registry.npmjs.org/jitsu/latest instead of http://github.com/api/v2/json/repos/show/nodejitsu/jitsu/tags
2. Use semver.gt() instead of >

nt

jitsu deploy on a package.json that does not have a version number, goes through most of the steps and then gives a bad error

info:   Welcome to Nodejitsu
info:   It worked if it ends with Nodejitsu ok
info:   Executing command deploy
info:   Authenticated as bmeck
info:   Analyzing your application dependencies in server.js

/home/bradley/Documents/nodejitsu/jitsu/lib/jitsu/package.js:378
    winston.silly('Local version: ' + pkg.version.magenta);
                                                 ^
TypeError: Cannot read property 'magenta' of undefined
    at Object.updateTarball (/home/bradley/Documents/nodejitsu/jitsu/lib/jitsu/package.js:378:50)
    at updateSnapshot (/home/bradley/Documents/nodejitsu/jitsu/lib/jitsu/commands/apps.js:90:19)
    at /home/bradley/Documents/nodejitsu/jitsu/lib/jitsu/package.js:230:74
    at /home/bradley/Documents/nodejitsu/jitsu/lib/jitsu/package.js:304:5
    at /home/bradley/Documents/nodejitsu/jitsu/node_modules/require-analyzer/lib/require-analyzer.js:64:14

we should be prompting this, and it is fixable

two problems here:

Usage is printed even though a valid command was entered.

server returns 500, yet the app is deployed

info:   Welcome to Nodejitsu
info:   It worked if it ends with Nodejitsu ok
info:   Executing command deploy
info:   Authenticated as dominictarr
info:   Analyzing your application dependencies in server.js
warn:   Your package.json version will be incremented for you automatically.
warn:   About to write /home/dominic/source/dev/nodejitsu-tester/helloworld-fullstacktest/package.json
data:   
data:   {
data:       main: 'server.js',
data:       name: 'helloworld-fullstacktest',
data:       scripts: { start: 'server.js' },
data:       subdomain: 'helloworld-fullstacktest',
data:       version: '0.0.0-49'
data:   }
data:   
prompt: Is this ok? (yes): 
warn:   Creating new snapshot for version 0.0.0-49
info:   Done creating snapshot 0.0.0-49
info:   Updating application helloworld-fullstacktest
info:   Activating snapshot 0.0.0-49 for helloworld-fullstacktest
info:   Starting app helloworld-fullstacktest
help:   
help:   Usage:
help:   
help:   Deploys an application using the following steps:
help:   
help:     1. Creates the application (if necessary)
help:     2. Creates or validates the package.json
help:     3. Packages and creates a new snapshot
help:     4. Stops the application (if neccessary)
help:     5. Starts the application
help:   
help:   jitsu deploy
help:   jitsu apps deploy
help:   
error:  Error running command deploy
error:  Nodejitsu Error (500): Internal Server Error
warn:   Error returned from Nodejitsu
error:  Error: Attempt to start running application
error:      at /root/nodejitsu/lib/nodejitsu/resources/app/controller.js:282:23
error:      at /root/nodejitsu/lib/nodejitsu/resources/app/controller.js:255:5
error:      at /root/nodejitsu/vendor/resourcer/lib/resourcer/resource.js:147:21
error:      at loop (/root/nodejitsu/vendor/resourcer/lib/resourcer/resource.js:63:17)
error:      at Function.runAfterHooks (/root/nodejitsu/vendor/resourcer/lib/resourcer/resource.js:65:10)
error:      at /root/nodejitsu/vendor/resourcer/lib/resourcer/resource.js:144:22
error:      at Object.callback (/root/nodejitsu/vendor/resourcer/lib/resourcer/engines/database.js:39:21)
error:      at /root/nodejitsu/node_modules/cradle/lib/cradle.js:276:26
error:      at IncomingMessage.<anonymous> (/root/nodejitsu/node_modules/cradle/lib/cradle.js:214:72)
error:      at IncomingMessage.emit (events.js:81:20)
info:   Nodejitsu not ok

We need to really be more judicious about color usage. Its loosing its relevance. There is a place and time for color, and unicode; an error, a success, something of special interest to the user. Keep in mind the distraction to guidance ratio.

jitsu list mentions a command jitsu apps restart but invoking it returns this:

info:   Executing command apps
error:  Action is required to run a command on resource: apps
help:   
help:   `jitsu apps *` commands allow you to work with your
help:   Applications on Nodejitsu. Valid commands are:
help:   
help:   jitsu apps create
help:   jitsu apps list
help:   jitsu apps deploy
help:   jitsu apps view    <name>
help:   jitsu apps update  <name>
help:   jitsu apps destroy <name>
help:   jitsu apps start   <name>
help:   jitsu apps restart <name>
help:   jitsu apps stop    <name>
help:   
help:   For commands that take a <name> parameter, if no parameter
help:   is supplied, jitsu will attempt to read the package.json
help:   from the current directory.
help:   
error:  Error running command apps
info:   Nodejitsu not ok

require-analyzer assumes there will be a main field in the package.json

although require-analyzer makes a noisy error when there is no main field, jitsu just exits silently.

When attempting to deploy an express application, the package.json did not auto-detect the express dep.

jitsu is a large portion of code which has nearly no tests.
Need tests for API client, then possibly for command line interface.

jitsu should be able to perform differential code updates instead of pushing an entire application snapshot every time.

We think the best approach might be to use a tool like bsdiff (http://www.daemonology.net/bsdiff/)

The caveat is that if we want to use an external program like bsdiff, we have to ensure that it is able to be bundled cross-platform for an easy npm install ( and be included as a dependency in jitsu )

@pquerna @indexzero @tmpvar - What do you guys think?

• Marak

This is probably more of an API issue, not sure if you want to implement in the client or server.

I'm trying to deploy an app via jitsu and it's failing to start.

I started a local haibu server and tried deploying locally and figured out the root cause of the issue. I have a 'throw' command in my code in case a config file isn't set and while haibu is catching this exception, it's not being passed to jitsu.

In this gist I've got:

• error logs that I get from jitsu
• error message from haibu that should be passed to jitsu
• some fishy stuff going on with jitsu where if I restart the app, then start it, it appears to be OK probably a different bug

@indexzero

Can you add a patch so we can specify default values for prompt.get calls? This way, we can pass in a default value and should the user choose to hit ENTER when prompted without typing any value, the default value will be used.

Thanks!

Got this error trying to deploy the examle http server from a new directory with jitsu v0.3.8. Code for server script and local platform versions also in gist.

https://gist.github.com/9ef85e97ab2aca19373a

pkginfo module isn't returning correct version number.

 require('pkginfo')('version');

doesn't seem to expose anything to the module scope, or any scope I could find.

https://github.com/nodejitsu/jitsu/blob/master/lib/jitsu.js#L58

With a fresh install of jitsu, no config file is created. Jitsu hangs while searching for a config file.

If a user attempts to:

 jitsu deploy

or

 jitsu create

in a folder which doesn't contain a valid package.json, jitsu should prompt the user to create a new package.json

i believe the minimal required fields are:

 name
 subdomain
 scripts:start

@indexzero Thoughts?

If the user selects a duplicate snapshot name, then jitsu should prompt the user if they want to overwrite the existing snapshot, and proceed.

Here's the error I'm getting:

https://gist.github.com/1009875

I'm able to reproduce this error 100% of the time with the following app:

https://github.com/goatslacker/nodeFighter/blob/master/server.js

My package.json looks like this:

{
  "name": "nodefighter",
  "subdomain": "nodefighter",
  "scripts": {
    "start": "server.js"
  },
  "dependencies": {
    "socket.io": "0.6.18"
  },
  "version": "0.0.0"
} 

1. needs labels on the fields (once you focus on them you aren't sure what the field is any longer.
2. need a confirm password field so you are sure you know what you thought you typed (since the characters are obscured).

get this error:

mismatch in remote request :

{ method: 'GET',
  uri: 'http://api.mockjitsu.com:90210/apps/mickey/application/snapshots',
  headers: 
   { Authorization: 'Basic bWlja2V5OnBvaXV5dHJld3E=',
     'Content-Type': 'application/json' } }
{ method: 'GET',
  uri: 'http://api.mockjitsu.com:90210/auth',
  headers: 
   { Authorization: 'Basic bWlja2V5OnBvaXV5dHJld3E=',
     'Content-Type': 'application/json' } }

/home/dominic/source/dev/jitsu/test/helpers/mock-request.js:147
      throw ex;
      ^
<error: TypeError: Cannot call method 'match' of undefined>
    at [object Object]._request (/home/dominic/source/dev/jitsu/test/helpers/mock-request.js:135:14)
    at [object Object].request (/home/dominic/source/dev/jitsu/lib/jitsu/api/client.js:55:8)
    at [object Object].list (/home/dominic/source/dev/jitsu/lib/jitsu/api/snapshots.js:34:8)
    at executeList (/home/dominic/source/dev/jitsu/lib/jitsu/commands/snapshots.js:42:21)
    at Object.list (/home/dominic/source/dev/jitsu/lib/jitsu/commands/snapshots.js:77:3)
    at runCommand (/home/dominic/source/dev/jitsu/lib/jitsu/commands.js:109:13)
    at /home/dominic/source/dev/jitsu/lib/jitsu/commands.js:123:7
    at Object.auth (/home/dominic/source/dev/jitsu/lib/jitsu.js:165:12)
    at Object.run (/home/dominic/source/dev/jitsu/lib/jitsu/commands.js:118:18)
    at execCommand (/home/dominic/source/dev/jitsu/lib/jitsu.js:124:20)

there is two problems here, I think vows or something is obscuring the error real error, since request-mock is throwing an error during an async opperation, I don't know where the TypeError is coming from. there is not .match in the stack traced code.

but more to the point of jitsu, since jitsu has a private reference to whether it's logged in or not, then test/commands/apps.js is dirtying the state for test/commands/snapshots.js. when snapshots is run jitsu is already logged in so it does do and auth request.

is an /auth request even necessary since we are using basic auth and credentials get sent on every request?

If a user attempts to login via jitsu and enters the wrong credentials, it should prompt them to try again a few times.

Currently, if the user puts in the wrong password they have to start over and type in their username again. This is not good UX.

This is a low priority ticket.

This is a low priority issue for jitsu, but we should add the ability for users to reset their password from the command line.

The tricky part might be exposing the reset command to work if no users are configured for jitsu. We'd need to allow users to run:

 jitsu forgot <username>

or

jitsu users forgot <username>

without having a valid auth in .jitsuconf