We have an ongoing problem that requires constant manual wrangling that i think we have brought up a couple times over the last 6-8 months, which is that machine limits that make sense during the day make less sense during the evening, especially the 3am-9am period when the farm is emptying up.
Suggestions were made for automatic limit control etc, but i was thinking, maybe it could be approached simpler… What if each job had an ‘overnight’ machine limit setting, in addition to the regular machine limit setting. If the overnight setting is enabled, in a time period defined in the repository settings all jobs would simply use that secondary limit setting. During regular hours, they would use the default machine limit.
Without centralized distribution of tasks (which i believe is off the table), i dont see how a ‘smart’ algorithm could be implemented that detects if there are idle slaves that could potentially render a job with still queued frames.
I guess one concern is that if we expose one job property to being scheduled like this, will there be a demand for other properties as well (pool, group, priority, timeouts, limits, etc)? There have been requests in the past for scheduling of other non-job settings, like pool priority on the slaves, and maybe there is a place for job settings as well.
Out of curiosity, do you guys run any scripts on a schedule to change Deadline settings? If so, maybe you could update the script to also go through all active jobs and update their machine limits based on the time of day that the script is run at.
Yeah you are right, maybe a generic mechanism for that would be better. I am just afraid of those ‘proper’ solutions, since if this becomes a huge feature request it will not happen for a long time, and this is an ongoing problem for us that we have had to schedule overnight wranglers for for the past 8 months.
We currently don’t have scheduled maintenance scripts managing deadline, the scripts the wranglers wrote and use are all manually controlled. Some jobs cant have their limits adjusted (simulations etc), so it quickly becomes a larger task. In general, I’m hesitant in frankensteining our own management system on top of deadline’s core…
When you don’t design and implement things properly though, that can create more problems down the road. Scheduling just seems like one of those things that needs to be fully fleshed out.
When it comes to scheduling right now though, we tend to recommend that studios write scripts that use the Deadline scripting API to update settings, and run then as scheduled tasks. Jobs that should be updated can have some Extra Info property set that the script could check for. That way, things like simulations can be ignored. Then it should be as simple as running the script at 3am and again at 9am to make the appropriate adjustments.
I definitely agree. I think it would be fantastic to be able to define arbitrary schedules for swapping limits, pools, groups, etc. (we already do this with pools), but I would like to see it done right.
As Ryan suggested, this is the kind of thing that can easily be done with a cron or other periodically scheduled task for now.
Don’t get me wrong, i like doing things properly. But i also like things being done.
I feel that sometimes larger (or smaller but non trivial) feature requests are deferred to the indefinite future. The question is, what does ‘for now’ mean? 2-3 more years or a couple of months? I have been on the autodesk betas for way too long for timelines and ‘future’ promises not to trigger bad memories combined with a stomach ache
We can definitely understand where you’re coming from, but you have to look at it from our perspective as well. Currently, we have hundreds items on our wishlist (many of which are larger or non trivial), and that list continues to grow. In 6.1, we churned out out hundreds of improvements, and we’re getting up there with 6.2 already: viewtopic.php?f=85&t=11421
We love getting requests from our users, and we truly pay attention to what you guys are asking for, but there are only so many large and non trivial features we can add to each release. That’s why we continue to make an effort to expose more areas of Deadline for customization. That way, if Deadline doesn’t do it out of the box, then at least our users can add their own functionality, like in this case.
For Deadline 8, we plan to look at all the job scheduling requests we have received and try to design a system that can support most of them, and I think a general scheduling system fits into that conversation. What this means is that during the design phase, we’ll consider what we can do for 8.0, and what we want to do later, and make sure we design it in a way that keeps those options open.
A prime example of this was when we designed the database backend for 6.0. We knew our users wanted the ability to suspend individual tasks, so we made sure our job and task states supported this, even though we knew we wouldn’t be able to add the feature during the 6.x cycle. Because we left that door open, the ability to suspend individual tasks is being added to 7.0.
Anyways, back to the original issue. It sounds like a custom script should be able to help you do what you want to do now, and we can definitely provide help if you guys have any questions or concerns about setting it up.
I feel your pain, but the quick-and-dirty solution would have worse fallout.
For instance, who defines when the “overnight” switch happens? Chances are my needs will be different from yours, and what about the guy who wants things to change four times a day instead of two? Now not only is there at least one new (and already-obsolete) property added to all jobs, but there are also additional repository preferences that need to be added, and which will again become deprecated in the future. But someone will still want to do things “the old way”, so now these obsolete support features have to be limped along into future Deadline versions.
Compare that to a cron or scheduled task: simple to set up, and made to do exactly the kind of thing you’re after. Sure, you have to write a few lines of script, but it will continue to run and do exactly what you want until you don’t need it to anymore.
We kind of do that already internally. We track if more than one user has requested a particular feature, and the more popular ones get greater consideration when building our roadmaps. I’ll have to talk to Chris about having a public facing system in the future.
