RFC: Node.js® 4.x support about nodejs-buildpack HOT 20 CLOSED

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/105040706.

from nodejs-buildpack.

👍 on Node.js v4 support.
It's a big release for the project and I definitely want to be able to use this on CF.

from nodejs-buildpack.

We want Node 4.x support on CF.

Some clients of our platform already asked whether node 4.x is supported.

Although it's possible to support node 4.x with docker image, I think this way is a little bit heavy compared with using buildpack.

from nodejs-buildpack.

+1 for Node.js v4 support

Need the node-gyp rebuild optimization feature.

from nodejs-buildpack.

Thanks to everyone who's commented so far. It's great to see some people interested.

But to be completely clear: I want to know what you think about the proposal, and the fact that we'll be moving away from auto-updating apps (via rootfs updates and dynamic linking) to forcing devs to own app updates (via restaging) for opennsl CVEs.

from nodejs-buildpack.

@charyorde Can you please open a new issue with a full description of the behavior you want from node-gyp? We've attempted to engage the nodejs community on this topic before, and there was a decided lack of participation. Would love to have help.

from nodejs-buildpack.

+1 to statically linking. Seems like the simplest and most straight forward solution. Lets not waste time on a more complex one until we need to.

Should only be an issue until a new stack is released based on Ubuntu LTS 16.04, right?

from nodejs-buildpack.

@flavorjones it's the same #31 which I believe is resolved in Node v4. Just need to be tested.

I'll favour "Static linking" considering that Node v4 release is a joint effort of the Node and io.js team. Release updates can only be better going forward.

from nodejs-buildpack.

+1 on static linking. Seems like the best tradeoff of concerns.

from nodejs-buildpack.

+1 we're going to productively deploy over 70 apps with node 4.2.x in the next weeks.

from nodejs-buildpack.

How do you guarantee the stability of the apps when you update the rootfs underneath without their knowledge?

from nodejs-buildpack.

@dotchev - Thanks for asking this question.

When we update the rootfs, that simply means that we've done a apt-get upgrade on the existing installed packages. So, if your app, or the interpreter used by your app, is dynamically linking against a shared library, things should Just Work™. Make sense?

The specific example here is that Debian/Canonical will make sure to backport (or simply merge) any patches that address CVEs into the packaged version of OpenSSL 1.0.1f. As long as the binary interface hasn't changed, this is generally considered a safe operation.

Updating the rootfs wouldn't be safe if the binary interfaces were allowed to change (e.g., upgrade libc from 2.19 to 2.20; or if we removed libraries; or if we changed the architecture of the rootfs (e.g., 64-bit to 32-bit); or if we changed the version of the libraries (e.g., update the rootfs from 14.04-based to 15.04-based).

Make sense?

from nodejs-buildpack.

👍 my two teams want to move our 20+ pcf apps to 4.x as soon as possible. Static linking sounds good.

from nodejs-buildpack.

+1 from me and my team on static linking as well. The NodeJS foundation is doing insanely well on getting out timely point releases. We have plans for a major rewrite of our entire framework from Scala to Node and need a reliable CF buildpack with NodeJS 4.2.x LTS as soon as you guys can.

Right now we are scraping by with a custom buildpack but an officially supported buildpack would be much appreciated.

from nodejs-buildpack.

It sounds like we have consensus on moving forward with the proposed plan.

We'll prioritize this work, and I'll update this Issue when we have something ready for people to beta-test.

from nodejs-buildpack.

Hello all,

We recently released nodejs-buildpack v1.5.1 which introduces support for Node.js 4.2.2.

Node.js 4.2.2 is the latest (as of 2015-11-06) version on Node's LTS branch, which we intend to support for the lifetime of the 4.x branch.

We welcome feedback on this version of Node, which you can provide by:

• opening a new Github Issue letting us know about any issues you experience using it
• commenting on this Github Issue if you've tried it and it's working as expected for you
• emailing cf-dev with any comments at all

Thank you!

-mike

from nodejs-buildpack.

Wow. Thank you

Testing away...

from nodejs-buildpack.

@flavorjones Thanks for that release! So which of the above proposals did you end up taking? Is openssl now statically linked, so everybody has to restage their app when a CVE is patched by the node team?

from nodejs-buildpack.

@voelzmo Correct, as proposed, we're statically linkling openssl 1.0.2 into the node binary.

At some point in the future, we may re-examine how we're handling this and attempt to dynamically link against a library in the rootfs; but I want to get more feedback from people to justify that decision before committing to it.

from nodejs-buildpack.

@flavorjones Thanks for the clarification. In the OP there was still more than 1 proposal, so I wanted to make sure I got that correctly.

from nodejs-buildpack.