@ -1540,8 +1540,25 @@ enough to implement in low-level backend components. That also means this
feature is visible and can be exploited but from our points of view it seems as
appropriate compromise in simplicity.
@todo: where is stored which workers can be used by supervisors and which runtimes are available, describe possibilities and why is not implemented automatic solution
Next thing relating backend management is storing its current state. This namely
concerns which workers are available for processing with what hardware and which
languages can be used in exercises. Another step is overall backend state like
how many jobs were processed on some particular worker, workload of broker and
workers, etc. The easiest solution is to manage these information by hand, every
instance of API has to have administrator which would have to fill them. This of
course includes only currently available workers and runtime environments,
backend statistics cannot be provided this way.
Better solution is to let these information update automatically. This can be
done two ways either it can be provided by backend on-demand if API needs them
or backend will send these information periodically to API. Things like
currently available workers or environments are better to be really up-to-date
so this can provided on-demand if needed. Backend statistics are not necessary
stuff which can be updated periodically. But it really depends on the period of
updates, if it is short enough then even available workers, etc. could be
updated this way and be quite up-to-date. However due to lack of time automatic
refreshing of backend state will not be implemented in early versions but might
Martin Polanka
8 years ago