-
Notifications
You must be signed in to change notification settings - Fork 93
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
[bug] Unable to connect to dashboard using Dask-Gateway and Labextension #1012
Comments
@viniciusdc has ideas for future work on this. For now we are going to move this to the v0.4.x release. Ideally the clusters should just show up without users needing to add the url. |
Do we know why it isn't working and how to fix?
But being able to add the url manually should be fixed in my opinion for 0.4 release. Folks use this and it is important for demos. How difficult is the fix? @viniciusdc @costrouc |
We will look at this issue for another 2 hours and then likely make the decision to move this to the 0.4.1 release. |
Moving this to v0.4.x |
@viniciusdc @costrouc This is still a regression. And is used by @rsignell-usgs heavily and by me and others in demo's what is the plan for investigating and fixing. |
Hi @dharhas, sorry for the delay with this, here are some details regarding this issue:
I will open a detailed issue on the lab-extension repo, as they might have a solution that we could implement. |
@viniciusdc is going to test this theory out but I believe I know the issue. The user is authenticated in the browser via the single sign on flow. This means that the cookies are stored in the browser not on the jupyterlab server. The dask lab extension has two parts code that runs in the browser and code that runs on the server. This check https://github.com/dask/dask-labextension/blob/main/dask_labextension/dashboardhandler.py is running on the server which does not have credentials. The way to test this is to run the code that is done on the lab extension and run it on both the server and browser. If this theory is correct the browser code will be the only one to run properly. I think that the lab extension broke once we started using forward auth in a |
This issue seems to corroborate our hypothesis dask/dask-labextension#190 |
So as we originally had expected, here is a simple test suit that shows the above-mentioned issue (now verified):
from dask_gateway import Gateway
gateway = Gateway()
options = gateway.cluster_options()
options
import requests
def fetch(url):
"Added this just in case we got stuck with redirects"
request = requests.get(url)
if request.status_code != 200:
print(request.headers)
msg = 'Error Code: %i on request'
raise Exception(msg % request.status_code)
return request
class Request():
protocol = ""
host = ""
url = _normalize_dashboard_link(parse.unquote(url), Request()) # just copied the function from source
individual_plots_url = url_path_join(url, "individual-plots.json",)
individual_plots_response = fetch(individual_plots_url)
# inspect fetch response, look for individual plots response
response_content = individual_plots_response.content
try:
assert individual_plots_response.headers.get('content-type') == 'application/json'
except AssertionError as err:
with open("response.html", "w+") as file:
file.write(individual_plots_response.text) from the above code snippet we got the following body response (rendered HTML from
const response = await fetch('https://quansight-beta.qhub.dev/gateway/clusters/dev.c05f4b01641747cfbf67a34712990ef5/individual-plots.json')
console.log(await response.json()) Wich returns the expected individual-plots json: {"Individual Bandwidth Workers": "/individual-bandwidth-workers", "Individual Progress": "/individual-progress", "Individual Gpu Utilization": "/individual-gpu-utilization", "Individual Graph": "/individual-graph", "Individual Groups": "/individual-groups", "Individual Nprocessing": "/individual-nprocessing", "Individual Compute Time Per Key": "/individual-compute-time-per-key", "Individual Workers Network Bandwidth": "/individual-workers-network-bandwidth", "Individual Workers": "/individual-workers", "Individual Cpu": "/individual-cpu", "Individual Aggregate Time Per Action": "/individual-aggregate-time-per-action", "Individual Gpu Memory": "/individual-gpu-memory", "Individual Cluster Memory": "/individual-cluster-memory", "Individual Profile": "/individual-profile", "Individual Workers Memory": "/individual-workers-memory", "Individual Memory By Key": "/individual-memory-by-key", "Individual Task Stream": "/individual-task-stream", "Individual Profile Server": "/individual-profile-server", "Individual Bandwidth Types": "/individual-bandwidth-types", "Individual Scheduler System": "/individual-scheduler-system", "Individual Occupancy": "/individual-occupancy", "Individual Cluster Map": "/statics/individual-cluster-map.html"} |
Just a bit more info, from ForwardAuth we can inspect the redirection to Keycloak for authentication:
|
@costrouc i think this issue still needs to be open right? as this is related to how labextension handles the oauth requests... |
I will be testing what was proposed in dask/dask-labextension#190 (comment) |
@viniciusdc did you ever have a chance to try the workaround? I'm having the same issue. |
Hi @jabbera, sorry for the late feedback on this. Yes, the workaround fixed the issue. To accomplish this just add an |
Some feedback on this, we have the fix already merged into |
to close this we need:
|
Describe the bug
Running the following on qhub
v0.3.13
andv0.3.14
generates an accessible link for the dask cluster dashboards, but we are unable to reuse that link to access the dask extension.successful generates a working URL for the dashboards (can be accessed):
Dashboard URL does not work:
Expected behavior
How to reproduce
The text was updated successfully, but these errors were encountered: