search

HDFGroup / hsds

Cloud-native, service based access to HDF data
https://www.hdfgroup.org/solutions/hdf-kita/
Apache License 2.0
129 stars 53 forks source link

runall.sh fails when SN_PORT is not 80 and there is no load balancer #70

Closed loichuder closed 3 years ago

loichuder commented 3 years ago

To my understanding, without load balancer, the SN is responding to front-end requests (https://github.com/HDFGroup/hsds/blob/master/runall.sh#L125).

Also, the check of STATUS_CODE (https://github.com/HDFGroup/hsds/blob/master/runall.sh#L160) uses the URL ${HSDS_ENDPOINT}/about which interrogates on default HTTP port 80 (or 443 if HSDS_ENDPOINT is HTTPS ?).

Therefore, changing SN_PORT makes this check fail while the server is running fine on SN_PORT.

I could make it work by changing the URL in the check to ${HSDS_ENDPOINT}:${SN_PORT}/about but it may not be the desirable behaviour with a load balancer.

jreadey commented 3 years ago

If you change the SN_PORT, you'll need to adjust the HSDS_ENDPOINT accordingly. E.g. if SN_PORT is port 80 and the DNS name is hsds.hdf.test, the endpoint is just "http://hsds.hdf.test".

On the other hand, if you set SN_PORT to 5101, you'll want the endpoint to be: "http://hsds.hdf.test:5101".

I guess the runall script could be a little smarter about adjusting the endpoint to account for the SN_PORT number, but considering all the possible permutations with load balancers, proxies, https connections, etc. it would likely be counter-productive to complexify it.

loichuder commented 3 years ago

I guess the runall script could be a little smarter about adjusting the endpoint to account for the SN_PORT number, but considering all the possible permutations with load balancers, proxies, https connections, etc. it would likely be counter-productive to complexify it.

Well, I think it is all right to adjust HSDS_ENDPOINT instead if there are no conflicts elsewhere. Thanks for the info.