for service creation, it does
calls_output.push_back(service_create(sname,body));
i can probably create a patch/MR for what I imagine it should be doing instead, if you'd like
(i.e. check the result of each service_create and service_predict call and if it's not good, return the failure and stop)
this is because the exceptions are caught within each call, e.g.
service_create
"simple" way would be to check on the
JDoc output object, and check on reported status.
Now, note that many services would most likely fail at first
predict call
This is why we included
service_predict as well, to load models up.
This is because we would have to unwind whatever went well and undo it :)
so at least the final JSON should return the errors if any
which I don't believe it does
and error check + cleanup script (autostart :) ), should be external to DD I think
you can't really take that as a given
why is that? if the start list file itself is a bad file or something like that, the entire dede process stops. wouldn't this fall under a similar scenario? something about the start list file itself is causing an error when creating services, so stop the entire dede process
at least we can't do that
but I see the point
what I mean by nop is that in our use cases we'd never kill DD
Now, I do see your point
It could be an option to the autostart call
To recover from failed init, I'd recommend restarting the process, aka docker or anything else
Hah, exactly - we do that currently, but with this option there isn't a good way to detect if there was a failed init :)
It could be an option to the autostart call
I like this thought, though
starting DD / stopping DD for instance, but I'm no expert in these matters, probably just a way for me to structure code and scripts etc...
especially life/death of processes. but yes, the option to autostart should work
as the http server I mean
thought I could do some simple JDoc compared to dd_create_201() or something