Failed to push component - Node.js

[lholmquist]

[kind/bug]

What versions of software are you using?

• Operating System: Fedora 29
• Output of odo version:

odo v0.0.17 (1d10127b)

Server: https://192.168.42.64:8443
Kubernetes: v1.11.0+d4cacc0

How did you run odo exactly?

I was following the "deploy an application using ODO" section on the readme, but instead of using the nodejs-ex example, i used one of the RHOAR Node.js Starter Applicaitons, https://github.com/nodeshift-starters/nodejs-rest-http, which is just a very basic express app.

after doing odo push, i get "failed to push to component", i then re-ran that with --v=9 and those logs are here:

https://gist.github.com/lholmquist/6bd5093c4aa46af9a5cfa7a0c4352102

Not really sure what is happening

minishift version is minishift v1.27.0+707887e

Actual behavior

failing to push my app to openshift

Expected behavior

I would expect that my node.js app should be deployed

Any logs, error output, etc?

[kadel]

It looks like this is the same error as #647

I have a suspicion that this might be related to minishift. Every time I saw this error it was with minishift and virtualbox driver.

@lholmquist What vm-driver are you using?

[lholmquist]

using the kvm driver.

So after reading that other issues comments, i saw what Jan said about how she had to fix the dependecies because something was missing. Looks like travis is erroring on the repo i was using because of a similar issue. I'm going to remove the package-lock.json and try again once my minishift comes back up

[lholmquist]

@kadel I got it working.

So i was having that same dependecy issue from that other thread. So i removed my package-lock.json, then did odo push. it still failed, but this time when building the component. So i then removed my local node_modules folder and ran it again, and everything worked.

So it looks like ODO is not ignoring node_modules folders? I would suggest that we ignore a users local node_module folder, since the npm install will run during the build. I haven't looked at odo's code to confirm that though.

I think we can close this then. Should i create the issue about ignoring the node_modules folders? Also what is the default Node image that is used with ODO? is it the SCL one or Rhoar one?

[geoand]

Seems like another reason why we need something like: #1085

[jorgemoralespou]

@lholmquist We will support .odoignore #1036 that will give you a means to prevent this issue.

We don't know much about node.js so any advice in what should be prevented from being pushed to the server would help us.

[lholmquist]

I think that is a good first step. by using the .odoignore, but if node.js is to be a first class citizen(which i would like to see for obvious reasons :) ), then it might make more sense to build some node.js specific ignores(to be defined) into the tool.

[jorgemoralespou]

That is the idea. After the foundations are set, we would probably look into more intelligence as @geoand mentions

[lholmquist]

@jorgemoralespou cool beans. Thanks for the info

[kadel]

I think we can close this then. Should i create the issue about ignoring the node_modules folders? Also what is the default Node image that is used with ODO? is it the SCL one or Rhoar one?

It depends on what you have in your cluster.

If you are running openshift origin/OKD than it is probably SCL one

[lholmquist]

how would i go about specifying my app to use the Rhoar node version?

[jorgemoralespou]

okd as well as ocp, in latest releases, should already have the RHOAR images available, although probably at different version levels.

You can check in github.com/openshift/library the imagestreams that get installed with OKD and with OCP, and then you should be able to know what tags are the RHOAR ones.

In OCP, these would be:

• 8-RHOAR
• 10
• latest(10)

In OKD, these would be:

• 8-RHOAR
• 10
• 11
• latest(11)

[surajnarwade]

@lholmquist , can you please confirm whether this issue still exists, I tested and works for me.
also as @jorgemoralespou mentioned, we do have support of .odoignore file.

[lholmquist]

I think we can close. I can always re-open if the issue persists