Deadline plugins deployment

[iLLiCiTiT]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

Deadline plugins are now inside client codebase, but it would be much better if they would be in private folder supplied in custom deadline Web UI with more information. E.g. which plugins are available, which version of the plugin (we should version the plugins BTW) and in which deadline addon was the plugin version released.

It would reduce size of client codebase and would be much easier for TD to deploy the plugins to deadline.

How would you imagine the implementation of the feature?

Requirement would be frontend that would show available plugins with their versions, the list would be prepared during create_package.py. Current content of client/ayon_deadline/repository/custom would be moved to root of repository. Each plugin would have own subfolder where would be content plugin itself and metadata with version and addon version when the version changed - this might be hard to follow. Content of plugin would be added to tar file (tar keeps file permissions on linux/mac) and metadata would be stored to single file, all located in private folder so they can be downloaded.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

[BigRoy]

I think separation may help from client - but I'm not entirely sure how we would serve these private files and why that would eventually be nicer "for the TD". Unless you meant, easier for the studio admin/TD who might not do development but does download the AYON addons from the market, then they'd access the files directly through the front-end?

[iLLiCiTiT]

I think separation may help from client - but I'm not entirely sure how we would serve these private files and why that would eventually be nicer "for the TD". Unless you meant, easier for the studio admin/TD who might not do development but does download the AYON addons from the market, then they'd access the files directly through the front-end?

Your question is your answer. Yes, private files that can be downloadable via web frontend.

[MustafaJafar]

I think separation may help from client - but I'm not entirely sure how we would serve these private files and why that would eventually be nicer "for the TD". Unless you meant, easier for the studio admin/TD who might not do development but does download the AYON addons from the market, then they'd access the files directly through the front-end?

Also for reference, more info about private files.

https://github.com/ynput/ayon-documentation/blob/d1fc3d884f9561ac982488e72026a8e0d40e4a55/website/docs/dev_addon_creation.md?plain=1#L539-L556

[m-u-r-p-h-y]

• the versioning part is even more important
• the similar "issue" we have with other plugins (like Adobe zxp files) these should be handled the same way as suggested here for deadline

[dee-ynput]

We should explore using LakeFS for all those, like we do for USD.

[BigRoy]

We should explore using LakeFS for all those, like we do for USD.

For files like this I must admit I have my worries about "obfuscating" downloadables like this to behind a fairly non-transparent wall. Having it part of the repository in a way adds maintainability of the files (which of course could auto-upload to lakefs if that makes any sense) but it also ensures that it works locally, offline, etc.

Note that these files are usually very small in size - and they are not dynamic (as far as I know) within the addon version. They are tied to the addon version and separating the distribution would mean just more maintenance.

Having it download from a LakeFS url it's unclear to me what the files may actually contain (and whether they are hence secure?). They may be just as secure as whatever the Git repo provides of course. But just wanted to mention it's definitely something that stands out to me already that it gives me the creeps because "I'm not sure what I'll get" but if it's in the repository I can see the code clearly. Also, note that studios may maintain, in a custom branch, their own custom code version of these files as well - which they'd of course also like to easily deploy to the artists in questions if they need to.

[MustafaJafar]

I think it should live in the private folder of the addon.
But, not sure how it should be exposed for artists to download. one idea is to have a frontend where there are download links that uses the ayon api to download the files.

Maybe there are other solutions, but I think they will be generic that also help with other addons with the same situation.
So, we may move this discussion to another issue/epic.

[dee-ynput]

Note that these files are usually very small in size - and they are not dynamic (as far as I know) within the addon version. They are tied to the addon version and separating the distribution would mean just more maintenance.

In this case those files are indeed not artifacts, and keeping them close to the code is indeed paramount 👍

But what about Murphy's statement then:

• the versioning part is even more important
• the similar "issue" we have with other plugins (like Adobe zxp files) these should be handled the same way as suggested here for deadline

We should definitely move this discussion to a broader topic and see if there's a one for all solution.