Hi Holger! I respond in *bold*
On Tue, 24 Apr 2018 at 12:00 Holger Freyther <hol...@freyther.de> wrote: > Hey! > > I look into using Taskit for a new development and wondered about some > features. What is the right upstream repository? *The main repo so far is https://github.com/sbragagnolo/taskit <https://github.com/sbragagnolo/taskit>* > What are the goals to get builds greens? *Don't have really a strategy yet, I did not have time to check on them. I can put my hands on it for a while and come up with a plan on that * > I wondered if somebody thought of remote task execution? > ** If by remote calls you mean through REST Api's or things like that, no yet. but is easy to use as: * *[ service call ] schedule. * *or* *result := [ service call ] future * ** If what you mean is to execute a program on the underlying operative system, we have a already a way to do it for linux (not tested on mac, but it may work there) * *result := [ :spec | * * spec* * command: 'bash';* * option: '-c';* * argument: command ] asOSTask future.* *The result deployed on the future is the stdout of the process .* *The text on the exception, the one on stderr of the process. * *Is based on OSSubProcess, it does not work properly with long stdout. * ** If what you mean is the execution of code deployed on other images, earlier versions of taskit had this feature, based on OSProcess, but we are not really ready for doing it for real. We need to be able to define if an image is suitable or not to run a command. * **If you mean something else, I would need more information :).* > What I am missing is handling for overload. E.g. before queuing too many > tasks I would prefer an exception to be raised (or the task > blocking/slowing down). Signalling an exception is probably more reasonable > as one task could queue another task (while >>#value is being executed...). > What are the plans here? I can mitigate by always using futures and using > >>#waitForCompletion:.. > **For raising exceptions on too much tasks you only need to set a custom made kind of queue. I don't think this is the way we want to go. Since there is not much to do in the case of 'too much tasks scheduled'. Is easy to try later from a do-it, but from an application point of view, is too much. * *For dealing with the sharing of resources, we have implemented the worker pools abstractions. * *When you do [ action ] schedule / [ action ] future, both created tasks are scheduled into the default runner. The default runner is a working pool with a default 'poolSizeMax' on 4, meaning, limit 4 processes working over the tasks. (this is a dynamic configuration, you can change it by * *TKTConfiguration runner poolMaxSize: 20. )* > > Are there ideas how to add remote task scheduling? Maybe use Seamless for > it? *Since you speak about seamless here, i suppose two different images, doesn't matter where. * *It's not a bad idea to go seamless, but i did not go through the first restriction of remote executions (if the remote image can or not execute the task and if both images share the same semantic for the execution), then i did not yet checked on which communication platform to use for it * > Have workers connect to the scheduler? Other ideas? *what do you mean by connection to the scheduler? The workers we use do not know their pools, if that is what you mean. * > Who would have time to review an approach and the code? *You can send it to me, Disclaimer, i am going on vacations for a while tomorrow* *Nice to know your interests! * *cheers.* *Santiago* > > cheers > holger >
