sample-app: Fix port of node-server-svc (80 to 8080) #6204
Conversation
Without this, following the instructions that don't require port forwarding (e.g. using "minikube tunnel") fails: the service is exposed on port 80, which is not what the frontend expects. After this commit the setup mimics that of the frontend service, which works both with and without port forwarding. Signed-off-by: Guzman <[email protected]>
knative-prow
bot
added
the
size/XS
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
This is needed because the node-server service listens on port 8080, and the K8s ref resolver doesn't support custom ports [1], and referring to the node-server-svc service yields: http://node-server-svc.default.svc.cluster.local/insert Instead of the correct URL: http://node-server-svc.default.svc.cluster.local:8080/insert Which results in hanging connections and eventually timeouts when adding new comments that pass the trigger's filter. [1] https://github.com/knative/pkg/blob/dcf159339de2fec9dde678a04cb7a354e912d2bf/resolver/addressable_resolver.go#L227 Signed-off-by: Guzman <[email protected]>
knative-prow
bot
added
size/S
|
Hi, When I reached step 6 of the sample app tutorial I noticed that the event never reached the subscriber (node-server service). If I understand correctly, this is because when the subscriber's destination is a reference to a service, the resolver assumes it listens on port 80, i.e. it doesn't consider the "port" part of the hostname. I lack experience to fully understand how this is supposed to work. Should I open an issue in pkg/ to handle this kind of situation? or, am I going in the wrong direction? Thanks! |
|
cc @Leo6Leo Could you recreate the problem reported here, does this fix it? |
| kind: Service | ||
| name: node-server-svc | ||
| uri: /insert # This is the path where the event will be sent to the subscriber, see /insert in node-server code: index.js | ||
| uri: http://node-server-svc.default.svc.cluster.local:8080/insert # This is the path where the event will be sent to the subscriber, see /insert in node-server code: index.js |
There was a problem hiding this comment.
Here we would still prefer using the ref instead of hardcoding the uri, as the uri might get changed based on the environment. The original yaml file without this change should work as expected.
There was a problem hiding this comment.
I agree the ref looks much nicer. However this is the only way I could make it work, see this explanation: #6204 (comment)
I just tried it out again just in case and observed the same behavior:
I think the ref is cleaner and the proper way to do this, but it seems to me that this method lacks support to discover the service port. And since it now is 8080 rather than the default 80, the event never reaches the node server.
| kind: Service | ||
| name: node-server-svc | ||
| uri: /insert # This is the path where the event will be sent to the subscriber, see /insert in node-server code: index.js | ||
| uri: http://node-server-svc.default.svc.cluster.local:8080/insert # This is the path where the event will be sent to the subscriber, see /insert in node-server code: index.js |
There was a problem hiding this comment.
Here we would still prefer using the ref instead of hardcoding the uri, as the uri might get changed based on the environment. The original yaml file without this change should work as expected.
| @@ -29,6 +29,6 @@ spec: | |||
| app: node-server | |||
| ports: | |||
| - protocol: TCP | |||
| port: 80 | |||
| port: 8080 | |||
There was a problem hiding this comment.
Could you also update the /solution/node-server/config/100-deployment.yaml file? @guzalv
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: guzalv The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Without this, following the instructions that don't require port forwarding (e.g. using "minikube tunnel") fails: the service is exposed on port 80, which is not what the frontend expects.
After this commit the setup mimics that of the frontend service, which works both with and without port forwarding.