feat: Allow pre-submit and post-submit callbacks

[Ahuge]

What was the problem/requirement? (What/Why)

When working in a studio, we often want to execute local validation of scene files before we allow a submission to the render farm. In other scenarios we may need to modify or transform the scene to prepare if for the render farm.

These two hooks allow for studio specified modification hooks to be optionally run before and after a submission completes.

What was the solution? (How)

This solution implements an on_pre_submit_callback and a on_post_submit_callback that take the same parameters as the on_create_job_bundle_callback.
The parameters match on_create_job_bundle_callback solely to provide flexibility in case the hook needs access to any of the settings of the job.

What is the impact of this change?

The impact of this change as it stands would be non-breaking. I would consider adding functionality in the deadline-cloud-for-XX adaptor packages to provide a developer friendly way to provide hooks externally (Out of the scope of this PR probably, but it could be environment variables pointing to hook files, or an import of a pre-determined package name for example)

How was this change tested?

Untested

Was this change documented?

Not currently documented

Is this a breaking change?

No it is a feature addition

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mwiebe]

Hey Alex, thanks for the PR! Your change looks good to me, but we'll need a tiny change to your commit/PR title to proceed. We're using Semantic PRs for some things like the changelogs, which means the commit messages need to follow https://www.conventionalcommits.org/. I think for this PR that means adding feat: to the start of it.

[epmog]

Thanks for the PR - I like the idea a lot!

Just a few comments.

In other scenarios we may need to modify or transform the scene to prepare if for the render farm.

If I'm understanding this correctly, we should be adding a test around the ability for the pre_submit callback to modify how the job gets created in on_create. As it is, the options can be inspected, but only some of the options are modifiable. Do we want all of them to be modifiable? ie. complete control?

[epmog]

I believe the intent here is to match what we pass into on_create_job_bundle_callback to give users full control before the job bundle gets created. So we should be including requirements here as well.

[Ahuge]

You're correct about that, I grabbed the on_create_job_bundle_callback signature from the else block.

I can move it below where requirements is defined.

[epmog]

This isn't initialized until a little bit further down, so it's currently undefined.

[Ahuge]

I can move the pre_submit callback lower down so that the requirements are included and have it within the "show_host_requirements_tab" branch if that is recommended to be included.

[Ahuge]

Thanks for the PR - I like the idea a lot!

Just a few comments.

In other scenarios we may need to modify or transform the scene to prepare if for the render farm.

If I'm understanding this correctly, we should be adding a test around the ability for the pre_submit callback to modify how the job gets created in on_create. As it is, the options can be inspected, but only some of the options are modifiable. Do we want all of them to be modifiable? ie. complete control?

Regarding what can be modified. My specific use cases I don't think need any modified, but I could see use for changing the following:

• queue_parameters
• asset_references
• settings
• Maybe the requirements?

The purpose probably isn't required as I would want this to only run pre-submit probably, I don't have a use case for job_history_bundle_dir or the UI object being passed through at this moment either, however my intention by passing all of this down was to increase flexibility as I am not the most familiar with this codebase.

If you think that those other parameters will not be needed in an on submit hook, then I can modify the signature.

Regarding the test to see what was modified. Are you referring to a unittest type test or a check to determine if any values were modified and then respond accordingly if they were?

If it is the latter I would be interested to know which you are most concerned about.
I am assuming that the UI dialog (self), settings, queue_parameters, asset_references, and requirements are modifiable objects and because they are being passed by reference, any changes that happen to them in the hook will be passed through due to the same reference being used later in the function.
The job_history_bundle_dir could be one that we test for modifications on, however I don't 100% know what it means to change the job_history_bundle_dir. My assumption is that it was essentially read only but not enforced.

[Ahuge]

I've added on to this implementation a little bit to help in my implementation of deadline-cloud-for-nuke HERE

The changes are around my tests and the new deadline.client.util.callback_loader module.

[epmog]

One thing I've been thinking about is the ability to run code before job creation already exists.

An application already passes in an on_create_job_bundle_callback which runs immediately after the proposed pre_submit callback. So an application can just add whatever it wants to its on_create, either directly to the function or something like a decorator.

The post-submit is a little more difficult since it's not about the creation of the job bundle, but the creation of the job in the service which isn't currently exposed. Though based on the identified use cases of pre_create and post_submit, it seems like pre_create is currently more desired.

Based on this and the new PR in the Nuke repository, it seems like the desire is more generally centered around customization of existing applications instead of forking/creating brand new ones. A few ideas off the top of my head of things we may want to provide customization on include, but are not limited to: create/embed custom gui controls, pre-populating values/overriding certain sticky settings, translate assets into openjd compatible ones, add custom steps/modify existing ones, etc.

I suggest that we create a feature issue and discuss the goals and use-cases there to ensure that we arrive at the right solution before defining a new interface to maintain. Thoughts?

[Ahuge]

Hey @epmog

An application already passes in an on_create_job_bundle_callback which runs immediately after the proposed pre_submit callback. So an application can just add whatever it wants to its on_create, either directly to the function or something like a decorator.

As far as deadline-cloud is concerned, yes an application passes that callback and it can just be modified, but in deadline-cloud-for-nuke, the on_create_job_bundle_callback is hardcoded and not easily accessible to the end-user-studio that may need customization of it, unless they "take over" the deadline-cloud submitter for Nuke.

The post-submit is a little more difficult since it's not about the creation of the job bundle, but the creation of the job in the service which isn't currently exposed. Though based on the identified use cases of pre_create and post_submit, it seems like pre_create is currently more desired.

In my main specific use case, I need to "revert" the scene to the state it was in pre submission. We're stripping doing things like converting SGTK write nodes to normal write nodes, and removing unused plugins (disconnected but still in the scene will cause the Nuke process to load and license them).

Based on this and the new PR in the Nuke repository, it seems like the desire is more generally centered around customization of existing applications instead of forking/creating brand new ones. A few ideas off the top of my head of things we may want to provide customization on include, but are not limited to: create/embed custom gui controls, pre-populating values/overriding certain sticky settings, translate assets into openjd compatible ones, add custom steps/modify existing ones, etc.

I suggest that we create a feature issue and discuss the goals and use-cases there to ensure that we arrive at the right solution before defining a new interface to maintain. Thoughts?

Agreed, I feel those are good potential use cases. I could see some sort of "pre-UI" step that allows for additional UI widgets (potentially), setting or overriding settings, and translation of assets.

The adding/modifying steps is an interesting idea, it may be difficult to define an interface that makes that easy for studios, perhaps we pass in the list of Python object representations of the job we're submitting and then receive a list of potentially modified ones back?

I think the functionality that I require (modifying the scene and reverting it) would work within that framework of a "pre/post UI" step.

I may create a fork of this for my clients in the meantime so that I can implement my dirty environment variable hooks to do my scene modifications but I would love to contribute to how this interface will be built.

Thanks for your thoughtful response and questions