Awesome, thanks WackyRabbit7 , AgitatedDove14 !

Ok thanks! And for this?

Would it be possible to support such use case? (have the clearml-agent setting-up a different python version when a task needs it?)

I didn’t use ignite callbacks, for future reference:
` early_stopping_handler = EarlyStopping(...)

def log_patience(_):
clearml_logger.report_scalar("patience", "early_stopping", early_stopping_handler.counter, engine.state.epoch)

engine.add_event_handler(Events.EPOCH_COMPLETED, early_stopping_handler)
engine.add_event_handler(Events.EPOCH_COMPLETED, log_patience) `

What do you mean by aws scalar?

As you can see, more hard waiting (initial sleep), and then before each apt action, make sure there is no lock

Here is the log from the instance

doesn’t really work unfortunately

the instances takes so much time to start, like 5 mins

on a p3.2xlarge instance

I sneaked a PR > https://github.com/allegroai/clearml/pull/319

edited the aws_auto_scaler.py, actually I think it’s just a typo, I just need to double the brackets

Interestingly, I do see the 100gb volume in the aws console:

Hey FriendlySquid61 ,
I ended up asking for full control of EC2 not to be blocked, so unfortunately I cannot give you a more precise list 😕

Try to spin up the instance of that type manually in that region to see if it is available

I did that recently - what are you trying to do exactly?

did you try with another availability zone?

ok, what is your problem then?

RobustRat47 It can also simply be that the instance type you declared is not available in the zone you defined

I would probably leave it to the ClearML team to answer you, I am not using the UI app and for me it worked just well with different regions. Maybe check permissions of the key/secrets?

Could you please share the stacktrace?

And now that I restarted the server and went back into the project where I initially deleted the archived experiments, some of them are still there - I will leave them alone, too scared to do anything now 😄

It seems that around here, a Task that is created using init remotely in the main process gets its output_uri parameter ignored

even if I explicitely use previous_task.output_uri = " s3://my_bucket " , it is ignored and still saves the json file locally

I killed both trains-agent and restarted one to have a clean start. This way it correctly spin up docker containers for services tasks. So probably the bug comes when a bug occurs while setting up a task, it cannot go back to the main task. I would need to do some tests to validate that hypothesis though

The task with id a445e40b53c5417da1a6489aad616fee is not aborted and is still running

of which task/process?

So the controller task finished and now only the second trains-agent services mode process is showing up as registered. So this is definitly something linked to the switching back to the main process.

I will try to isolate the bug, if I can, I will open an issue in trains-agent 🙂

-> seems to run properly now