Tickets #459
Comments
timurhai
added a commit
that referenced
this issue
Feb 17, 2020
AfWatch GUI can edit tickets in a left parametes panel. References #459.
timurhai
added a commit
that referenced
this issue
Feb 17, 2020
timurhai
added a commit
that referenced
this issue
Feb 20, 2020
timurhai
added a commit
that referenced
this issue
Feb 21, 2020
On task start/stop render updates all parent pools tickets usage. References #459.
|
I think this is also solving #311 . no? If you give the root pool 100 "Nuke" tickets and 5 "NukePlugin" tickets and a block is defined to need 1 "NukePlugin" and 1 "Nuke" ticket per task, only 5 tasks IN TOTAL with the ticket "NukePlugin" will run on the pool! No?! |
|
Hi. |
timurhai
added a commit
that referenced
this issue
Feb 24, 2020
timurhai
added a commit
that referenced
this issue
Feb 25, 2020
Host stores tasks tickets usage (even if it has not any tickets). It needed to check pool host tickets count/usage check. Usage only ticket is a ticket with -1 count. AfWatch shows host tickets needed for usage only with dash-dot border. References #459.
timurhai
added a commit
that referenced
this issue
Mar 3, 2020
There is no need to read temporary (count==-1) ticket from store. Usage should be zero on store reading. This all can happen when server was restarted with tasks running. On a task reconnection, tickets usages will be incremented. References #459.
timurhai
added a commit
that referenced
this issue
Mar 9, 2020
Now it works correctly. This parameters now in af::Farm class. So they are the same for af::Pool and af::Render classes. At least now we need less code, at least for GUIs (for now). And this is more clean. References #459.
|
We started to use tickets in a real production. |
Closed
|
We are using it about several months. It seems that it works. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ticket is like a "named" capacity.
Pools, renders and tasks (job blocks) can have some tickets.
Ticket has a name and count.
( tickets is a std::map<std::string, int32_t> )
If host has "MEM"x64 tickets, it can run 2 tasks with MEMx"32" tickets.
If pool has "NET"x1000 tickets, all its renders can run tasks with a total "NET" tickets sum <= 1000.
Root pool can have 100 "NUKE" tickets to limit licenses.
"hbatch_mantra" block can have "HYTHON"x1 and "MANTRA"x1 tickets for corresponding limits.
ps
We are already using pools at work. Now we have some extra farm within some special network. So our studio very-very need some mechanism to balance network load. And i have think up "tickets" (i decided to call named capacity so), and already started to implement it as we are very need it.
pps
Sorry, but other issues and #451 pull request (#451) will be postponed. But i definitely will be back to it.
The text was updated successfully, but these errors were encountered: