I think an updated system overview is long past due.
Думаю давно следовало сделать небольшое овервью
Taskflow name is temporary, as it turned out there is a library named taskflow also dealing with distributed task management... So that will be changed before first public release. Well, i should have done a better name research beforehand.
Имя Таскфлоу оказалось уже занято библиотекой со схожей областью... Придется придумать новое имя перед релизом. Чтож, надо было лучше исследовать вопрос заранее.
"Taskflow" consists of 3 major components: scheduler, worker and viewer. All 3 are currently parts of the same package. However since viewer requires much more heavy GUI dependencies - it makes sense to separate it into it's own package
"Таскфлоу" состоит из 3х компонент: шедулер, рабочий и вьюер. Все 3 - часть одного питон пакеджа. Однако учитывая, что вьюер тянет тонну тяжелых интерфейсных зависимостей - имеет смысл его выделить в отдельный пакедж
Component names should speak for themselves for anyone familiar with render farm managers.
Имена компонент говорят сами за себя для любого, имевшего дело с рендерфермами.
Scheduler - is one central hub that keeps track of all tasks, all nodes, it moves tasks around and does scheduling - meaning it gives tasks' payload to workers to invoke.
Шедулер, он же планинировщик, - центральный узел системы, следящий за всеми тасками (задачами), нодами, и собственно всей логикой их поведения, а так же назначает нагрузки, созданные тасками, на рабочих.
Worker - is what is run on every machine you want to be part of your "render farm". Worker executes payload, there can be more than one worker on the same physical machine sharing resources efficiently
Рабочий - это то, что запускает нагрузки. Рабочие запущены на всех машинах, которые должны выполнять работу. Более одного рабочего может быть запущено на одной машине - в таком случае они будут эффективно делить ресурсы.
Viewer - is just a UI program to interact with the system through scheduler. Yes, ui should be web based, but i cannot do web... so here you are a standalone client.
Вьюер - это просто интерфейс, через который юзер может наблюдать за системой и влиять на неё. Да, интерфейс должен быть вебовым, но я не умею в веб, может разберусь как-нибудь позже... а пока что - вот отдельный клиент.
The system was intended to require minimum configuration: you just start scheduler on one machine, workers on others, and it just works, no config required. In reality there are some unavoidable configuration required, like setting up paths to your DCC software at least, though taskflow tries to scan for it automatically too.
Система задумывалась как требующая минимальной ручной настройки: запускаешь шедулер на одной машине, рабочих на других, и всё работает. На деле всё же от некоторой конфигурации не уйти, например скорее всего потребуется настроить пути до установленных софтов, хотя таскфлоу и пытается найти их автоматом.
Each DCC can create tasks connecting to the scheduler with plugins, like, for example, with special hdas in houdini.
Каждая сторонняя программа может соединяться с шедулером с помощью плагинов, как, например, специальные ассеты в гудини.
So, what's done?
Таки что готово?
Scheduler, worker and viewer are working to some extent, the only plugin though currently made is for houdini. Everything is implemented in python, but it's not that bad...
Все компоненты до определенной степени работают, плагины сделаны пока только для гудини. Всё сделано в питоне, но всё не так плохо...
Scheduler uses pretty trivial scheduling algorithm, but it works pretty well even for thousands and tens of thousands of tasks, so it is enough for now. Though resource management is not yet implemented. Scheduler by default uses local network broadcasting to allow all other components to connect to it without the need to set up any configurations. As a backend SQLite database is used. It should be relatively simple to port it to any other SQL based DB, but I don't see the point since scheduler is the only one process that will ever access it, unless later scheduler is made to be distributed.
Шедулер использует тривиальный алгоритм назначения рабочих, однако пока что этого вполне достаточно, и он работает вполне немедленно даже на десятках тысяч тасков. Однако менеджмента ресурсов пока нет. Шедулер по умолчанию использует броадкасты, чтобы найти рабочих, вьюеров и потенциально прочие компоненты, чтобы не нужно было везде вбивать вручную адреса. Бэкэнд шедулера - SQLite база данных, так что при необходимости должно быть не сложно портировать шедулер на другие SQL базы данных, смысла в чём я не вижу, если только вдруг шедулер не станет распределённым.
Worker: well, it's task is just to launch things, so there's not much expectations. Workers support custom environment handlers: a task defines certain environment requirements for it's payloads. Handler can be reimplemented to do anything, but the current standard implementation just reads software requirements from payload and provides such environment for the task's payload to be executed in, taking software paths from configuration.
Рабочий: чтож, тут всё довольно просто - он просто запускает подготовленные нагрузки. Рабочие поддерживают так называемые "настройщики среды выполнения" (environment handlers): таск задает определенные требования к среде, в которой нагрузка будет выполняться. Эти настройщики могут делать впринципе что угодно, но текущий стандартный просто составляет среду из путей, прописанных в конфигах к запрашиваемому софту.
Viewer can perform almost all task and node manipulations supported by scheduler. Here you create your node graphs. Since there's no job concept - tasks can be filtered by groups, which are assigned both automatically and manually and are inherited by all children tasks. Nodes cannot be filtered by groups yet, but that feature will be implemented in future. The UI update is performed in a most stupid way now - full state is received from scheduler every time, which is bad in theory, but in practice data sizes are still too small for this to become a real problem. That will be optimized in future, but probably after initial release.
Вьюер на данный момент поддерживает почти все операции, которые позволяет шедулер. Именно во вьюере собираются графы нод. Так как концепта job по аналогии с другими фарм менеджерами в таскфлоу нету - таски могут фильтроваться по группам, которые создаются автоматически и вручную, и наследуются дочерними тасками. Обновление информации из шедулера на данный момент происходит по самой топорной схеме - полное обновление раз в секунду, что крайне неэффективно в теории, но на практике объемы данных пока что достаточно малы, чтобы такое обновление стало проблемой. В будущем обновление состояния будет оптимизировано.
So what's missing before initial release?
Итак, чего по моему мнению не хватает для начального релиза?
- Graph layout tools. Scheduler does not care about node positions, each viewer user can layout nodes as it wants. Without layout tools when someone opens a big graph for the first time - it's just a huge unreadable mess, so layout tools are a must.
- Инструментов для лэйаута графов нод. Шедулер не следит за позициями нод, так что каждый вьюер может отрисовывать графы как ему вздумается. Тогда когда кто-то открывает уже существующий граф, созданный кем-то другим, впервые - все ноды создаются в нуле, что, естественно, вообще никак не читаемо и требует их муторного ручного растаскивания.
- A minimal user manual is a must, no explanation needed
- Минимальная инструкция пользования - обязательна
- Basic resource management has to be implemented
- На данный момент не реализован контроль ресурсов рабочих
- some UI features like copy-pasting, multiple task selection and node filtering need to be done, not mentioning ctrl+z
- не хватает некоторых базовых функций во вьюере, например копи-пейста, множественного выделения тасков и фильтрации нод. я уж не говорю о контрл+з
So overall i'd say it's almost usable at this point.
Вцелом я бы сказал, что системой уже почти можно пользоваться