Also, are you using a self-hosted server? How did you deploy it

There's an ES REST Api command to get the current template

UnevenDolphin73 when started, the agent will typically create the queue it was provided if it does not exist - can that be the case?

In any case, feel free to ping us here if you have any questions or run into any trouble 🙂

By the way, best practice for Trains when running on the cloud is to limit external access to 8081 to your office/home IP address

ElegantCoyote26 /uploading_file is the temporary filename provided in the URL while the file is still being uploaded, so I assume the issue is that the upload was not completed

@<1627115732695257088:profile|TastyOctopus79> It seems I was incorrect in my suspicion - examining the log I see this:
gnutls_handshake() failed: The TLS connection was non-properly terminated
Which seems to indicate some networking issue on the client-side accessing Git - this is a known issue that may be affected by network proxies or some network setups

@<1531807732334596096:profile|ObliviousClams17> can you share a screenshot of the task's execution section?

Hi ReassuredTiger98 , this is not yet possible in clearml-agent, but I'm sure you can add some cron job to handle that using the docker command line

Hi @<1577468611524562944:profile|MagnificentBear85> , assuming all the server components are up and running (i.e. if you're using docker-compose, for example, all docker containers should be running and reporting logs), the server will never produce this kind of output - this is almost always a result of some network connectivity issue

Is this after you've created the index using the instructions I sent?

Hi TenseOstrich47 ,
Currently there isn't a way to remove them - they're considered read-only and can't be modified (both the project and the experiments within).
Are they bothering you that much?

Also, if the autoscaler is running from your remote machine, it's basically a client trying to connect to the server, and the server address it uses must be a valid address of the remote server. The agent services container running as part of the docker compare of the server uses the internal docker network (which cannot be accessed outside of the docker compose services)

🙂

Well, probably an optimization side-effect

and are there times when you try to run it in parallel?

This would require a code-change, though (we welcome PRs 🙂 )

Hmm, interesting

Also, the apiserver container log should also shed light on this matter as it lists all the configuration files it reads

in the agent configuration, use:
agent.hide_docker_command_env_vars.extra_keys: ["DB_PASSWORD"]

Hi @<1686547380465307648:profile|StrongSeaturtle89> , usually you'd either run all locally or all remotely. What's your specific use case?

Well, if you need an external IP, you'll probably want to configure the docker params to use the host network

Hi WickedBee96 , which clearml agent version are you using? I think a similar issue was fixed in a recent release (python 3.10 detected as 3.1)

@<1529271085315395584:profile|AmusedCat74> ?

Can you share the task log?

It looks like you've set CLEARML_ENV to an unsupported value

For #2: You're partially right. They all run fine without the agent-services container. This container is also not required for running your own agents. It only functions as a "services" oriented cpu-only agent designed to run maintenance tasks - since these kind of tasks do not require q GPU and take up relatively low CPU, this agent basically takes advantage of the already-running server machine 🙂

We can either fix the documentation, or make sure we wrap this text accordingly inside the call

@<1533257407419912192:profile|DilapidatedDucks58> I would assume the docker container is just not starting up correctly for some reason - but the do let logs are essential to understand the issue ..

Again a DNS issue with the .ml domains... Mostly with Google DNS Servers, it seems