The agent also uses a different clearml.conf
, so it should not matter?
Interesting, why wonβt it be possible? Quite easy to get the source code using e.g. dill
.
But since this has come up a lot recently, any updates on #340? π
I'm trying, let's see; our infra person is away on holidays :X Thanks! Uh, which configuration exactly would you like to see? We're running using the helm charts on K8s, so I don't think I have direct access to the agent configuration/update it separately?
Let me test it out real quick.
AFAIU, something like this happens (oversimplified):
` from clearml import Task # <--- Crash already happens here
import argparse
import dotenv
if name == "main":
# set up argparse with optional flag for a dotenv file
dotenv.load_dotenv(args.env_file)
# more stuff `
That's what I thought @<1523701087100473344:profile|SuccessfulKoala55> , but the server URL is correct (and WebUI is functional and responsive).
In part of our code, we look for projects with a given name, and pull all tasks in that project. That's the crash point, and it seems to be related to having running tasks in that project.
AgitatedDove14
hmmm... they are important, but only when starting the process. any specific suggestion ?
(and they are deleted after the Task is done, so they are temp)
Ah, then no, sounds temporary. If they're only relevant when starting the process though, I would suggest deleting them immediately when they're no longer needed, and not wait for the end of the task (if possible, of course)
Thanks for the reply @<1523701827080556544:profile|JuicyFox94> ! I'll debug more and let you know
BTW AgitatedDove14 following this discussion I ended up doing the regex way myself to sync these, so our code has something like the following. We abuse the object description here to store the desired file path.
` config_path = task.connect_configuration(configuration=config_path, name=config_fname)
included_files = find_included_files_in_source(config_path)
while included_files:
file_to_include = included_files.pop()
sub_config = task.connect_configuration(
configurat...
Ultimately we're trying to avoid docker in AWS autoscaler (virtualization on top of virtualization seems redundant), and instead we maintain an AMI for a faster boot sequence.
We had no issues when we used pip
, but now when trying to work with poetry
all these issues came up.
The way I understand poetry
to work, is that it is expected there is one system-wide installation that is used for virtual environment creation and manipulation. So at least it may be desired that the ...
FWIW, we prefer to set it in the agentβs configuration file, then itβs all automatic
The instance that took a while to terminate (or has taken a while to disappear from the idle workers)
From our IT dept:
Not really, when you launch the instance, the launch has to already be in the right VPC/Subnet. Configuration tools are irrelevant here.
I guess I'll have to rerun the experiment without tags for this?
Don't even need to specify json=...
π Thanks!
The logs are on the bucket, yes.
The default file server is also set to s3://ip:9000/clearml
I'll try with 1.1.5 first, then 1.1.6rc0
... and any way to define the VPC is missing too π€
It is installed on the pipeline creating the machine.
I have no idea why it did not automatically detect it π
The api.files_server
is set to the MinIO endpoint s3://ip:9000/clearml (both locally and remotely) The sdk.development.default_output_uri
is set to the MinIO endpoint (both locally and remotely) When we call Task.init
I do not set the output_uri
at all I get the logger directly with task.get_logger()
Hi SuccessfulKoala55 !
Could you elaborate on how best to delete these from the database?
We're using 1.1.5 at the moment -- I'll make sure everyone updates to 1.1.6 on Monday.
That solution does not work for us unfortunately -- the .env
is an argument from argparse, and because we cannot attach non-git files to a remote task (again issue #395), we have to first download CLI arguments for remote execution and ensure they exist on the remote agent.
Oh and clearml-agent==1.1.2