MUP uses current stable node.js, which doesn't allow web sockets with newest meteor

[arunoda]

MUP uses current stable node.js, which doesn't allow web sockets with newest meteor

[stephentcannon]

Why not use this strategy for MUP?

Instead of installing Node install meteor and use the node packaged with that version of meteor, which will always be the correct version of Node.

That way no node install and it is self-contained.

Arunoda wrote this article. We are not using MUP in production but we used this strategy in our meteor.conf start up script. We are evaluating using MUP and would think this would be a more logical way to deploy. Maybe wrong?

http://meteorhacks.com/how-meteor-uses-node.html

[kcaylor]

Ok. So that would imply using 'setupNode': false in mup.json (or omitting 'setupNode' completely), which is consistent with the actual file mup.json provide in example/. However, the Readme.md strongly suggests 'setupNode': true is a good idea (WARNING:....). Since meteor is bundling its own node.js I think clarifying the anticipated use-case for 'setupNode' in the Readme.md would be helpful.

[arunoda]

Hi,

I was aware of this node version issue. I should downgrade upgrade mup to use it. May be we can have a mup update feature which update the node which is exactly used my meteor.

@stephentcannon with mup, I used a different strategy to build the bundle locally and send it to the server. Which simply runs it as a node app.
The reason for this is the instability of npm-registry which failed some of deployments. Now we know it works.

[stephentcannon]

I haven't tested the setupNode: false yet.

@arunoda You should be able to pull which version of node the target deployment app is using. Your mnode identifies where the version of node is that the application is using.

Using mnode on your dev plat identifies which node is being used. Not as in the literal $ which node but rather where the node binary is.

For example on my dev box mnode shows...
/home/steeve/.meteor/tools/09b63f1ed5/bin/node

When I run
$ /home/steeve/.meteor/tools/09b63f1ed5/bin/node --version

Output is...
v0.10.22

There might be an easier way to identify the proper node version to install in production. That is just the only way I knew how right now.

That way MUP always installs the correct version. Alternatively, maybe with setupNode there could be a nodeVersion?

I though mup reconfig is what mup update would be?

Personally, I like that MUP is not installing meteor and not pulling the code down onto the production box to do the bundle. It is more secure.

[arunoda]

Hi,

I think with setupNode enabled, mup should ask server to use the exact node
version used by meteor when they deployed. I think that can be done.

I'll try to ship a new version this week.

On Fri, Feb 14, 2014 at 10:29 AM, steeve cannon [email protected]:

I haven't tested the setupNode: false yet.

@arunoda https://github.com/arunoda You should be able to pull which
version of node the target deployment app is using. Your mnode identifies
where the version of node is that the application is using.

Using mnode on your dev plat identifies which node is being used. Not as
in the literal $ which node but rather where the node binary is.

For example on my dev box mnode shows...
/home/steeve/.meteor/tools/09b63f1ed5/bin/node

When I run
$ /home/steeve/.meteor/tools/09b63f1ed5/bin/node --version

Output is...
v0.10.22

There might be an easier way to identify the proper node version to
install in production. That is just the only way I knew how right now.

That way MUP always installs the correct version. Alternatively, maybe
with setupNode there could be a nodeVersion?

I though mup reconfig is what mup update would be?

Personally, I like that MUP is not installing meteor and not pulling the
code down onto the production box to do the bundle. It is more secure.

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/25#issuecomment-35055945
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[stephentcannon]

Ya, I checked mup deployed with node v0.10.25 and my local dev run mnode on it shows .meteor/tools/09b63f1ed5/bin/node --version

[stephentcannon]

@arunoda How were you thinking about accomplishing this?

I took a look and the node script uses the chris-lea ppa which pushes the latest node version.

What do you think about having a "nodeVersion" param in the mup.json?

If undefined install latest.

If version specified attempt version install i.e.: "nodeVersion": "v0.10.22"

If "meteor" then get the version from the "app" like mnode does. "nodeVersion": "meteor"
(or that could be "app")

Or would you like something like
nodeSettings:{
"setupNode": true,
"nodeVersion": "v0.10.22"
}

What were you thinking about version management? nvm or n maybe?
https://github.com/creationix/nvm
or
https://github.com/visionmedia/n

I might have time to take a look at this, but I want to make sure the solution is inline with your plans.

[jonjamz]

+1

[stephentcannon]

@arunoda Did you see my post on this issue? I just wanted to follow up because I think there are some strategies. I haven't worked on this but I have reviewed the code and if nvm or n is used instead of chris lea's ppm's then we would be able to allow people to specify the node version. Later if they leave it out we could check the local project like mnode does and then fall back to that version. I haven't worked on this because it is your project and I don't want to go in a direction you aren't interested in. Please advise.

[arunoda]

Yes. I totally agree with you. Sorry for the late reply. I was bit busy
with the APM. You don't need to use nvm or n.

Use this strategy.

• send the node version meteor used with mnode (use mnode programatically)
• check if that node version is installed
• if not to download use a script like
  thishttps://github.com/arunoda/nodemiral-mongodb/blob/master/scripts/install.sh#L48-L66
• install our node to a custom place since it does not pollute the system
  wide node
• add NODE_PATH env variable to node_modules folder of the node installation

What do you think?

On Thu, Feb 27, 2014 at 10:24 AM, steeve cannon [email protected]:

@arunoda https://github.com/arunoda Did you see my post on this issue?
I just wanted to follow up because I think there are some strategies. I
haven't worked on this but I have reviewed the code and if nvm or n is used
instead of chris lea's ppm's then we would be able to allow people to
specify the node version. Later if they leave it out we could check the
local project like mnode does and then fall back to that version. I haven't
worked on this because it is your project and I don't want to go in a
direction you aren't interested in. Please advise.

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/25#issuecomment-36210281
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[stephentcannon]

@arunoda Oh yeah, congrats on APM, got the email this morning, can't wait to check it out! I will read this over and see if I can pull this off and to a pr. If it is above my head I will let you know.

[arunoda]

Thanks.

Sure. I have used a undocumented(some parts) npm module called
nodemiralhttps://github.com/arunoda/nodemiralto talk with SSH.

That is something we used for devops for sometimes.

On Thu, Feb 27, 2014 at 10:38 AM, steeve cannon [email protected]:

@arunoda https://github.com/arunoda Oh yeah, congrats on APM, got the
email this morning, can't wait to check it out! I will read this over and
see if I can pull this off and to a pr. If it is above my head I will let
you know.

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/25#issuecomment-36210830
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[stephentcannon]

@arunoda what about use case where they haven't run meteor on their project and haven't installed or run mnode? If we use mnode programatically then meteor-up becomes dependent on mnode.

[arunoda]

we are doing a bundling process, so if we use mnode after that we don't
need to worry about meteor run.
Oops, I've not added an way to use mnode via a nodejs api. I think I can
work on that.

On Thu, Feb 27, 2014 at 6:00 PM, steeve cannon [email protected]:

@arunoda https://github.com/arunoda what about use case where they
haven't run meteor on their project and haven't installed or run mnode? If
we use mnode programatically then meteor-up becomes dependent on mnode.

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/25#issuecomment-36236918
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[stephentcannon]

Please see PR zodern/meteor-up#29

[arunoda]

Thanks @stephentcannon
Tested and released a new version: 0.1.12