5

Been using Openshift / Node.Js for a while now, mostly problem free. Usually I install (via npm) modules to my local (windows) machine, develop, than git-deploy to Openshift and all goes well.

I recently added the jsdom module (which again works fine locally), but when I git-deploy (no errors on the git push), I get this error when I try to use my app:

.../app-root/runtime/repo/node_modules/jsdom/node_modules/contextify/node_modules/bindings/bindings.js:91
throw err
^
Error: Could not locate the bindings file.

Followed by a list of directories Node attempted to look for it. When I check the remote server for these directories, they are missing (even though they exist on my local machine and were pushed). If I attempt to copy the folders over via ftp, I get this error:

Invalid ELF header

Which I understand is because the contextify module did not build on the server (ie, I copied it over).

Note that my dependencies in my package.json contain "jsdom":"0.1.7".

After some googling, I next tried to manually install the module on the remote server via npm. This produced the following error:

npm http 304 https://registry.npmjs.org/mime
npm http 304 https://registry.npmjs.org/combined-stream
npm http 304 https://registry.npmjs.org/async

> contextify@0.1.7 install /var/lib/openshift/52...52/nodejs/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild

npm http GET https://registry.npmjs.org/assert-plus/0.1.2
npm http GET https://registry.npmjs.org/asn1/0.1.11
npm http GET https://registry.npmjs.org/ctype/0.5.2
npm http 304 https://registry.npmjs.org/ctype/0.5.2
npm http 304 https://registry.npmjs.org/assert-plus/0.1.2
npm http 304 https://registry.npmjs.org/asn1/0.1.11
Traceback (most recent call last):
  File "/opt/rh/nodejs010/root/usr/bin/gyp", line 15, in <module>
    import gyp
ImportError: No module named gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/opt/rh/nodejs010/root/usr/lib/node_modules/node-gyp/lib/configure.js:417:16)
gyp ERR! stack     at ChildProcess.EventEmitter.emit (events.js:98:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:784:12)
gyp ERR! System Linux 2.6.32-431.el6oso.bz844450.x86_64
gyp ERR! command "node" "/opt/rh/nodejs010/root/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /var/lib/openshift/52...52/app-root/runtime/dependencies/nodejs/node_modules/jsdom/node_modules/contextify
gyp ERR! node -v v0.10.5
gyp ERR! node-gyp -v v0.9.5
gyp ERR! not ok

This is where I'm now stuck. It would seem the remote server is missing "gyp", and I have no idea how to solve that. I have the "node-gyp" module installed, and I have read about other npm/openshift issues here, but don't know how to apply them to my problem.

Any help would be greatly appreciated. Thanks in advance!

JBalzer
  • 105
  • 6
  • I have the same issue. Any clue or still stuck? /: – Kevin Chavez Jul 03 '14 at 07:05
  • I've also got this problem. – Jack Guy Sep 22 '14 at 21:52
  • as time passes, more of us will run into this... https://bugzilla.redhat.com/show_bug.cgi?id=1103113 That's the bug in their bugzilla I think - but clearly no-one willing to fix it? There are some hacky workarounds but that defeats the point of PAAS? Note: it works OK on Heroku... –  Feb 28 '15 at 00:53
  • i had a similar problem. try rename node_modules and reinstall with npm install. – Philip J. Fry Mar 03 '15 at 12:30

1 Answers1

0

Per John Peat in question comments, and Ben Parees comment 4 at the bugzilla issue he linked, it seems that the OpenShift Node.js 0.10 cartridge is missing a path to GYP in its shell path variables.

Your set of cartridges may not be providing GYP dependencies. Python may not be available at all. I just confirmed there is no PYTHONPATH environment variable in their Node.Js cartridge, and the system isn't set up to do nmp as user from commandline.

Try declaring jsdom in packages.json, per Redhat docs.

If that fails, or you need a more personal setup, like providing your own Python, then the answer may be to build a cartridge. That would also be an opportunity to move up to Node 0.12 or Io.js.

Victor Segall
  • 51
  • 2
  • Obviously making your own cart. is an option - it's not ideal but it seems the only path out of this... Of course if you're a paying OpenShift customer you can raise this with their support directly and perhaps get them to add the bits you need to the stock cartridge perhaps? –  Mar 06 '15 at 22:31
  • No word yet from @JBalzer on which part of the answer did it for him. If rolling your own cartridge is the answer, then no, not ideal, but Node 0.12 and this sort of issue case isn't the only reason to do that. A downside is, if I remember correctly, OpenShift will not "scale" custom cartridge gears in response to traffic. Check the docs, though. – Victor Segall Mar 08 '15 at 06:30
  • I'm guessing @JBalzer may have moved-on - I just raised the bounty here because it's better than making a new version of the same problem? :) –  Mar 13 '15 at 02:37