-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Houdini deadline submission #33
Comments
As far as I'm able to tell, The issue description is mentioning refactoring Houdini deadline submission. I'll just quote it here: Vanilla Deadline ROPIn order to use the vanilla deadline ROP node. we need to figure a way that only performs the publishing. So, the node network actually looks more like this More info about it in his demo on Github. Also, I did quick search about adopting vanilla It seems that deadline rop supports specific standalone plugins, and I couldn't find a way to extend its functionality to support AYON. |
Guess this issue should be after #2. |
AYON is already supported by Deadline, this is literally the AYON plugin for Deadline https://github.com/ynput/ayon-deadline/tree/develop/client/ayon_deadline/repository/custom/plugins/Ayon As for customizing Houdini's Deadline integration (i.e. to add env vars so the AYON environment gets injected) it's also pretty easy, you just need to provide your customizations under the
|
Following up the discussion, I think there are two ideas mentioned:
Tagging @BigRoy |
Hey @antirotor |
As far as I can remember, this issue is related to two topics:
|
Thanks for the summary @MustafaJafar ✨ |
Hello, I'm sorry if this comes out as a bit harsh but I think the approach this PR is taking to support caching in the farm is wrong and over engineered.
First of all, caching in the farm (and rendering or any other Houdini processes) are already supported by third-party toolsets (Deadline, HQueue, Tractor...) and in WAY more powerful ways that this PR tries to accomplish and the OP plugin framework can manage. This is duplicating all of that logic in OP and adding 1,398 more lines to the already super complex code base!! Most Houdini TDs are already familiarized with those vanilla workflows and having them learn this other "black box" approach through OP is backwards and doesn't add any benefit in my opinion. You can see an example of a very normal submission to the farm here ynput/OpenPype#5621 (comment)
OpenPype shouldn't try to orchestrate the extract/render dependencies of the Houdini node graph, that's already done by these schedulers/submitters, we just need means to be able to run OP publish tasks of the generated outputs, but without doing any gimmicks, just taking a path, a family, a few other data inputs and registering it to the DB so it runs the other integrate plugins of OP like publishing that to SG/ftrack as well (and ideally the API for doing that in OP should be super straightforward to call it from anywhere! the current json file input isn't the best access point to that funcionality). If we wanted to help the existing vanilla submission OP could provide a wrapper of the vanilla submitters so it sets some reasonable defaults and we could intersect the submission to run some pre-validations on the graph... set some parms that might be driven by the OP settings or create utility HDAs to facilitate the creation of the submitted graph so frame dependencies are set correctly and chunk sizes for simulations... but that's it, we don't need to reinvent the wheel by interpreting how the graph needs to be evaluated.
On the other hand, I still don't quite get why the existing
submit_publish_job
is limited to "render" families and why it's not abstracted in a simple reusable module that any plugins that require to submit to Deadline can reuse it. This PR showed how a lot of the code had to be duplicated again with most of the lines exactly the same, doubling in technical debt. This PR https://github.com/ynput/OpenPype/pull/5451/files goes in the right direction in abstracting some of those things but the right approach should be to remove all of the noise from submit publish job that's render specific and make use of the same util module every time we just need to run an OP publish task in the farm. However, as ï said initially, I don't think we should even take this approach for Houdini and we should just leverage the existing farm submitters code, but this is relevant for any other tasks that we choose to submit to the farm, we are going to have to write a "submit_<insert_family_type>_job" set of plugins for each?Extra notes:
Originally posted by @fabiaserra in ynput/OpenPype#4903 (comment)
[cuID:OP-7455]
The text was updated successfully, but these errors were encountered: