-
Notifications
You must be signed in to change notification settings - Fork 643
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
api.files_server
without a port causes pipeline to fail
#1264
Comments
Hi @lastsecondsave, I'm not sure I understand - the error you show mentions port 443 - this means the 443 port appears in the URL registered for this artifact (it's explicitly written in the DB), so the problem seem to be that the URLs you're trying to access have the 443 port, while the files_server setting does not have it. |
They were created by the another agent. So the agent
The task is being scheduled on the agent
My assumption was that the first agent has nothing to do with the problem, since it already had a "workaround". And seems like my yesterday debug session was accidentally caused by someone who initially configured it). Still, the presence or absence of the default ports should not cause anomalies. |
I'll have to disagree on the last one - in general it's possible to have several different services on different ports, which is why the SDK uses the exact service endpoint to loop for configured credentials - I'm not sure why different clients (agent, SDK) should have different endpoints defined (with or without port) - you should simply decide on one and use it consistently |
It's not possible to have different services on |
Describe the bug
I'm trying to run a pipeline with this step:
The function is not relevant, it is not being called. When an agent picks up the step, it fails with:
URL mentioned is correct and the file can be downloaded with a browser.
To reproduce
This is how ClearML is deployed in our environment:
The problem above disappears if I explicitly set the port for the
files_server
:My wild guess is here you create an object's name from the url. This makes the port a part of the name (you can see it in the log). And here you reconstruct the url, which probably will look like
https://files.clearml.xxxxx.net/:443/...
. And this one causes 404.Expected behaviour
URLs without ports should not cause any issues.
Environment
The text was updated successfully, but these errors were encountered: