marco69v / orchestrator Goto Github PK

due to the envirnment where it was build, orchestrator works well if the engines are on hosts (without the network suffix, this is another issue) that are of kind:

engine001
engine002
engine003 and so on. if the name are different with no serial is the most problem. if are in sequence but are not starting from 1 it can be managed into the scheduler.bash but must be reviewed to be more elastic

if an api has more that "page_size" objects as response we are taking only the first page_size results

If a response is bigger then the max page_size should be used page parameter to get the desired page having the result of interest.

the header of the response display the number of object returned and the total of objects. this must be managed:

{
"_pageInfo": {
"numberOnPAge": 100,
"total": 122
},
[...]

during a live execution with many jobs in queue we saw that for one it was remeined on a cpu but was not executed. going to check what was happened but a hanged job cannot stay for ever on a cpu for nothing.
Must create a logic to clean cpu that are blocked by jobs having problem

(for example, after 3 times that a job stay in JUST_INSERTED it can be removed and signed as errored for further analisys at the end)

if you call orchestrato with a job in lower case, checkstatus wont work if jobs was created in upper case on the engines