Well, if the task has completed without completing the uploads, it would stay that way

Can you use environment variables?

SmugDolphin23 which agent version did you use?

Hi @<1729309131241689088:profile|MistyFly99> , please see here:
None
I think this is exactly the issue you're experiencing

The console errors are inconsequential

Hi @<1687643893996195840:profile|RoundCat60> ,
This is more of an AWS-scope issue, but as far as I know, the permissions required are something like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-name",
                "arn:aws:s3:::bucket-name/*"
            ]
        },
        {
            "Effect": "Allow...

Which AMI are you referring to?

Back up the indices from the original setup and import them to the new ES

FierceRabbit20 I think the issue is that the controller code is not from source control, but a single file, and so there's no repo attached (hence the agent does not use the requirements.txt)

Hi WackyRabbit7 ,
I'm not sure I follow - you have 0.15.1, and the UI suggests you upgrade to 0.161 - this is the expected behavior...

The instructions specify you should curl the latest docker-compose, which contains a reference to allegroai/trains:latest - currently, this image in docker hub is for Trains Server 0.16.1

The reference in the docker-compose.yml is for allegroai/trains:latest

That's why we're here 😄

Don't assume 🙂 - just try to issue the command

Also, MotionlessCoral18 , you can take a look at the fileserver and see if you detect any errors, using sudo docker logs clearml-fileserver

The server is basically oblivious to https - any reverse proxy implementing SSL termination should handle HTTPS and forward the decoded requests to the server upstream using HTTP - if your reverse proxy doesn't do that, than you're effectively no doing SSL termination but simply forwarding whatever you get to the server, and the server won't handle HTTPS

For the credentials and server address

is it known?

That's actually strange since this comes immediately after forcing the task to the stopped state

What server version are you using?

ResponsiveCamel97 is looks like one of the shards in ES is not active, I suggest using ES API to query the cluster status and the reason for the shards status

it's not supported natively in the APIClient

I would suggest talking a look at pipelines: None

VirtuousFish83 see below what I see when I run the example twice and compare:

It looks like not all the containers are up... Try sudo docker ps and see if the apiserver container is restarting...

Yes, but how do you plan to run the inference?

However, the server returns auth.login with 200 , so the question is why isn't the token generated by that response stored in the browser

Can I see the response headers from the auth.login call? Specifically, the set cookie header - I suspect the cookie might be domain-specific and thus not stored by the browser (since I can't see it used in the following requests)

Can you show the response for the auth.login call and the request and headers for the following calls?

@<1562973095227035648:profile|ThoughtfulOctopus83> I think you can simply include the registry name as part of the docker image name

Hi FloppyDeer99 ,
the users.get_all should be sent to the apiserver, not to the webserver. In any case, the header will not affect this request as the server will be using your user's identity (encoded in the authorization header) to resolve the company