Sent it to you via DM!

platform: "tensorflow_savedmodel" input [ { name: "dense_input" data_type: TYPE_FP32 dims: [-1, 784] } ] output [ { name: "activation_2" data_type: TYPE_FP32 dims: [-1, 10] } ]

yeah, that's fair enough. is it possible to assign cpu cores? I wasn't aware

I have done this but I remember someone once told me this could be an issue... Or I could be misremembering. I just wanted to double check

is that what you mean?

web_server:

Is this a possible future feature? I have used cometML before and they have this. I'm not sure how they do it though...

but it's been that way for over 1 hour.. I remember I can force the task to wait for the upload. how do i do this?

it says method not allowed when i try to access that url

well.. it initially worked but now i get the same thing 😕 SuccessfulKoala55

{"detail":"Error processing request: [Errno 2] No such file or directory: '~/.clearml'"}

api_server:

i don't think the conf is an issue. it's been deployed for a long time and working. models from yesterday correctly display the url

unicorn is an alias for the ip of the machine the server is hosted on

see this for example

okay. what do you suggest?

I think the issue is that the host is not trusted... it looks like it looks into the index

this is the code that's giving me trouble 🤔

fp32 seems to be floating point 32 so my preprocessing seems wrong

Monsieur Martin! 1.3.2

so it tries to find it under /usr/bin/python/ I assume?

I think it's still caching environments... I keep deleting the caches (pip, vcs, venvs-*) and running an experiment. it re-creates all these folders and even prints

Requirement already satisfied: idna<4,>=2.5 in /usr/local/lib/python3.8/dist-packages (from requests>=2.20.0->clearml==1.6.4->prediction-service-utilities==0.1.0) (3.4)
Requirement already satisfied: charset-normalizer<4,>=2 in /root/.clearml/venvs-builds/3.8/lib/python3.8/site-packages (from requests>=2.20.0->clearml==1.6....

yep, setting it to -1 is still caching envs..

I understand! this is my sysadmin message:
"if nothing else, they could publish a new elasticsearch image of 7.6.2 (ex. 7.6.2-1) which uses a newer patched version of JDK (1.13.x but newer than 1.13.0_2)"

any 7.6.2-x if I'm not wrong

can you elaborate a bit on the token side? i'm not sure exactly what would be a bad practice here

is this a possibility?

hi SuccessfulKoala55 ! has the docker compose been updated with this?>

In fact I just did that yesterday. I'll let you know how it goes

"this means the elasticsearch feature set remains the same. and JDK versions are usually drop-in replacements when on the same feature level (ex. 1.13.0_2 can be replaced by 1.13.2)"