Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function failed to get deployed on the ocp cluster when using namespace/project other than default #242

Open
odockal opened this issue Apr 22, 2022 · 9 comments
Labels
kind/bug Something isn't working upstream

Comments

@odockal
Copy link
Collaborator

odockal commented Apr 22, 2022

When deploying the function to the ocp cluster I am encountering following error on the deployed pod:

Log from the terminal:

$ func deploy -p '/home/odockal/Temp/vscode-function/debug-node-test' -i quay.io/odockal/debug-node-test:latest -v -n debugging -r ""
Building function image
2022/04/22 12:42:43.767479 DEBUG:  Pulling image gcr.io/paketo-buildpacks/builder:base
....
Pushing function image to the registry
The push refers to repository [quay.io/odockal/debug-node-test:latest] (100%)
latest: digest: sha256:d170d7d5f07db5912afa3351232527b224abbcf642760ca18f095c28d1e4e16c (100%)
Deploying function to the cluster
Waiting for Knative Service to become ready
Error: knative deployer failed to wait for the Knative Service to become ready: timeout: service 'debug-node-test' not ready after 120 seconds

And the pod log:

2022/04/22 11:04:14 unlinkat /workspace/node_modules: operation not permitted
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_npm-install/launch-modules/exec.d/0-setup-symlinks': exit status 1
@odockal odockal added kind/bug Something isn't working upstream labels Apr 22, 2022
@odockal odockal changed the title Function failed to get deployed on the ocp cluster Function failed to get deployed on the ocp cluster when using namespace/project other than default Apr 22, 2022
@odockal
Copy link
Collaborator Author

odockal commented Apr 22, 2022

Steps to reproduce:

  1. CRC deployed with enough resources / have access to the ocp cluster
  2. install serverless operator
  3. creat serving and eventing projects/instances
  4. create some custom project, ie: testspace
  5. set namespace/project to testspace project
  6. open knative tab and verify that tree item for function is testspace, refresh if not
  7. create node-http function project in the function view
  8. build the function
  9. Assert: project it built correctly
  10. Assert: Run it locally - is accessible on localhost:8080
  11. Deploy function on cluster
  12. Assert: function is available on cluster and accessible via given route
  13. Actual result: Is not accessible (404), pod log shows error

@lance
Copy link

lance commented Apr 22, 2022

Just to be clear that this is not related to Knative Functions or the VSCode plugin, the following few steps can reproduce this error without too much effort.

mkdir testapp
cd testapp
npx express-generator
pack build --builder paketobuildpacks/builder:base quay.io/USERNAME/express
docker push quay.io/USERNAME/express # if this is the first time you've done this, you'll need to configure quay so the image is NOT private
kn service create expresss --image quay.io/USERNAME/express

# It will hang here ^C to kill it
# Creating service 'express' in namespace 'func-demo':
#
#   0.045s The Route is still working to reflect the latest desired specification.
#   0.045s ...
#   0.059s Configuration "express" is waiting for a Revision to become ready.

# See what's happened
kn service list
NAME      URL                                                                          LATEST         AGE    CONDITIONS   READY     REASON
express   https://express-func-demo.apps.cluster-sgbsg.sgbsg.sandbox1122.opentlc.com                  92s    0 OK / 3     Unknown   RevisionMissing : Configuration "express" is waiting for a Revision to become ready.

@mhdawson
Copy link
Member

From the title: namespace/project other than default. So all works fine if the default namespace is used? @lance I think from your comment I can't tell if you were using the default namespace or not?

@lance
Copy link

lance commented Apr 25, 2022

@mhdawson I do not think the namespace is the issue here. I don't remember whether I was using the default namespace with my test or not, but I've seen this issue reproduced enough that I would be surprised if that was the problem (given that the easiest way to try something is to use the default).

@mhdawson
Copy link
Member

@lance thanks, that is what I wanted to confirm

@jonirap
Copy link

jonirap commented Jul 20, 2023

Any news on this front?
I'm getting the same answer when trying to use npm workspaces with the pack builder

@mhdawson
Copy link
Member

@lholmquist should this be an issue in https://github.com/nodeshift/faas-js-runtime instead?

@lholmquist
Copy link

I'm not seeing how this is related to the faas-js-runtime.

Actual result: Is not accessible (404), pod log shows error

would've been nice if we had what this error output was though

@alperdedeoglu
Copy link

I think this is an issue with pack builder, having the same issue with npm workspaces. Somehow can not create a symlink.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working upstream
Projects
None yet
Development

No branches or pull requests

6 participants