AWS Thinkbox Discussion Forums

Request: Nondestructive job range modification

Deprecated Deadline 6 Beta Discussion
#1

It would be really nice if job frame ranges could be modified without affecting rendering tasks unless frames that were currently rendering were being removed.

I’m guessing that the current mapping between task IDs and task frame ranges make some things prohibitively difficult or impossible:

  • Modifying the “frames per task” value, thus dividing the frame ranges of currently-executing tasks
  • Inserting frames ahead of currently-executing tasks

However, it seems like it should be possible to add tasks to the end of a job without disrupting anything, which would be very useful by itself.

I understand that things like modifying the “frames per task” value or removing frames from a running task will most likely always require the task to be re-queued (unless the storage schema for tasks and frames is dramatically overhauled), but I’m hopeful that in some future release, changes to the frame range that do not overlap with a running task will not require it to be re-queued.

It would also be nice if ranges could be modified using the REST API.

Thoughts on any of this?

Thanks

#2

This is something that we’ve had on the wishlist for a while, and one idea we’ve had is to store frames as individual objects and have the notion of a “task” simply be metadata that describes how many frames a slave grabs at a time. However, this isn’t something we’ve fully fleshed out, so we don’t know what the implications are.

You’re right that adding tasks shouldn’t be a disruptive operation, and maybe refactoring the task object is the way to do this, but again, it isn’t something we’ve fully fleshed out.

So to answer your question, it is something we’ve thought about, but it’s not something that’s on the current roadmap.

I’ll add your request to support modifying frames from the REST API to the wishlist though. Should be easy enough to do for v7.

Cheers,
Ryan

#3

Thanks Ryan. Obviously a full overhaul isn’t something I would expect to see anytime soon, but I’m glad it’s at least on the radar.

#4

Fully in agreement, this is something thats come up here several times as well

Privacy | Site terms | Cookie preferences