500 Response when creating pod using API
I always getting error when trying to create POD using API. Always the same response "create pod: There are no instances currently available"
10 Replies
unfortunately this is one of the places where we can't give you super great error messages on how to fix it. This means for the set of parameters you specified, no machines match all the constraints. There are too many possible causes of this for us to narrow one down to suggest.
Try removing all params you don't actually care about - they are all optional, we have defaults for them on the backend. Once you get to a configuration that works, add things in one by one to see if that was a reason machines were unavailable
In future, we might spend some extra time to get potential machines with slightly altered versions of your input, and suggest to you "hey, your input works if you get rid of AllowedCudaVersions so maybe try that". For now that is a bit sophisticated
another option for us on the backend is to run the sql query with EXPLAIN and look at how many rows were left after each WHERE clause, and report back the ones that led to a sufficiently high % reduction of the search space. also pretty sophisticated but not as expensive since we're running the query anyway
hahah so basically like reverse of what i suggested
I think this is because of the cuda version 12.7 specified
most of our machines are at cuda version 12.4
Isnt a 400ish response code more appropriate?
debatable, you as the user didn't do anything wrong by submitting this set of parameters, we just didn't have the infrastructure on the backend to support it
if you try in future maybe we do have that combination of settings and the input does work, so problem is on our end
I tend to go "its not my fault" way when i get a 500 response code so 😄
But your explaination makes sense
i looked for a 400 response code that covered this kind of situation, namely that nothing went wrong on the server but the request did not succeed. 409 sounds the closest but not exactly it?
Agreed, seems good for this. With the extra info( suggestion that might help user with the filters) is better
looking it up, it seems some people's perspective is that since the error happened at the business logic layer rather than the http layer, I should return 200 but with some error struct in the response body. To that I say, nah. As a consumer I like being able to assume that 200 / 2xx actually means everything went fine and my error handling code doesn't need to parse any further unless response is not 2xx
REST is hard 😪