mirror of
https://github.com/ynput/ayon-core.git
synced 2025-12-24 21:04:40 +01:00
Fix: Locally copied version of last published workfile is not incremented (#4722)
* Fix: Locally copied version of last published workfile is not incremented * fix subset first match * correct anatomy name * Fix typo and linting * keep source filepath for further path conformation * fetch also input dependencies of workfile * required changes * lint * fix case only one subset * Enhancement: copy last workfile as reusable methods (#6) * Enhancement: copy last published workfile as reusable methods (WiP) * Added get_host_extensions method, added subset_id and las_version_doc access, added optional arguments to get_last_published_workfile * Plugged in the new methods + minor changes * Added docstrings, last workfile optional argument, and removed unused code * Using new implementation to get local workfile path. Warning: It adds an extra dot to the extension which I need to fix * Refactoring and fixed double dots * Added match subset_id and get representation method, plus clan up * Removed unused vars * Fixed some rebasing errors * delinted unchanged code and renamed get_representation into get_representation_with_task * This time it's really delinted, I hope... * Update openpype/modules/sync_server/sync_server.py reprenation isn't the right spelling (: Co-authored-by: Félix David <felixg.david@gmail.com> * Changes based on reviews * Fixed non imperative docstring and missing space * Fixed another non imperative docstring * Update openpype/modules/sync_server/sync_server.py Fixed typo Co-authored-by: Félix David <felixg.david@gmail.com> Co-authored-by: Hayley GUILLOT <hayleyguillot@outlook.com> Co-authored-by: Félix David <felixg.david@gmail.com> * Fix: syntax error * fix single subset case * Restore sync server enabled test in hook * Python2 syntax * renaming and missing key case handling * Fix local workfile overwritten on update in some cases (#7) * Fix: Local workfile overwrite when local version number is higher than published workfile version number (WiP) * Changed regex search, clean up * Readded mistakenly removed newline * lint * remove anticipated functions for cleaner PR * remove funcs from entities.py * change to get_last_workfile_with_version * clean * Update openpype/modules/sync_server/sync_server.py Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com> * removed get_last_published_workfile_path * moved hook to sync server module * fix lint * Refactor - download only if not present * Refactor - change to list instead of set * Refactor - removing unnecessary code last_published_workfile_path must exists or we wouldn't get there. Use version only from that. * Refactor - removing unnecessary imports * Added check for max fail tries * Refactor - cleaned up how to get last workfile * Updated docstrings * Remove unused imports Co-authored-by: Félix David <felixg.david@gmail.com> * OP-5466 - run this on more DCC * Updated documentation * Fix - handle hero versions Skip hero versions, look only for versioned published to get max version id. * Hound * Refactor - simplified download_last_published_workfile Logic should be in pre hook * Skip if no profile found * Removed unwanted import * Use collected project_doc Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com> * Use cached project_settings Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com> --------- Co-authored-by: Félix David <felixg.david@gmail.com> Co-authored-by: Sharkitty <81646000+Sharkitty@users.noreply.github.com> Co-authored-by: Hayley GUILLOT <hayleyguillot@outlook.com> Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com> Co-authored-by: Jakub Ježek <jakubjezek001@gmail.com>
This commit is contained in:
Petr Kalis
GitHub
parent
b8ce6e9e9c
commit
fec104de8e
4 changed files with 379 additions and 148 deletions
|
|
@ -7,80 +7,112 @@ sidebar_label: Site Sync
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Site Sync allows users and studios to synchronize published assets between
|
||||
multiple 'sites'. Site denotes a storage location,
|
||||
which could be a physical disk, server, cloud storage. To be able to use site
|
||||
sync, it first needs to be configured.
|
||||
|
||||
:::warning
|
||||
**This feature is** currently **in a beta stage** and it is not recommended to rely on it fully for production.
|
||||
:::
|
||||
|
||||
Site Sync allows users and studios to synchronize published assets between multiple 'sites'. Site denotes a storage location,
|
||||
which could be a physical disk, server, cloud storage. To be able to use site sync, it first needs to be configured.
|
||||
|
||||
The general idea is that each user acts as an individual site and can download and upload any published project files when they are needed. that way, artist can have access to the whole project, but only every store files that are relevant to them on their home workstation.
|
||||
The general idea is that each user acts as an individual site and can download
|
||||
and upload any published project files when they are needed. that way, artist
|
||||
can have access to the whole project, but only every store files that are
|
||||
relevant to them on their home workstation.
|
||||
|
||||
:::note
|
||||
At the moment site sync is only able to deal with publishes files. No workfiles will be synchronized unless they are published. We are working on making workfile synchronization possible as well.
|
||||
At the moment site sync is only able to deal with publishes files. No workfiles
|
||||
will be synchronized unless they are published. We are working on making
|
||||
workfile synchronization possible as well.
|
||||
:::
|
||||
|
||||
## System Settings
|
||||
|
||||
To use synchronization, *Site Sync* needs to be enabled globally in **OpenPype Settings/System/Modules/Site Sync**.
|
||||
To use synchronization, *Site Sync* needs to be enabled globally in **OpenPype
|
||||
Settings/System/Modules/Site Sync**.
|
||||
|
||||
|
||||
|
||||
### Sites
|
||||
### Sites
|
||||
|
||||
By default there are two sites created for each OpenPype installation:
|
||||
- **studio** - default site - usually a centralized mounted disk accessible to all artists. Studio site is used if Site Sync is disabled.
|
||||
- **local** - each workstation or server running OpenPype Tray receives its own with unique site name. Workstation refers to itself as "local"however all other sites will see it under it's unique ID.
|
||||
|
||||
Artists can explore their site ID by opening OpenPype Info tool by clicking on a version number in the tray app.
|
||||
- **studio** - default site - usually a centralized mounted disk accessible to
|
||||
all artists. Studio site is used if Site Sync is disabled.
|
||||
- **local** - each workstation or server running OpenPype Tray receives its own
|
||||
with unique site name. Workstation refers to itself as "local"however all
|
||||
other sites will see it under it's unique ID.
|
||||
|
||||
Many different sites can be created and configured on the system level, and some or all can be assigned to each project.
|
||||
Artists can explore their site ID by opening OpenPype Info tool by clicking on
|
||||
a version number in the tray app.
|
||||
|
||||
Each OpenPype Tray app works with two sites at one time. (Sites can be the same, and no syncing is done in this setup).
|
||||
Many different sites can be created and configured on the system level, and
|
||||
some or all can be assigned to each project.
|
||||
|
||||
Sites could be configured differently per project basis.
|
||||
Each OpenPype Tray app works with two sites at one time. (Sites can be the
|
||||
same, and no syncing is done in this setup).
|
||||
|
||||
Each new site needs to be created first in `System Settings`. Most important feature of site is its Provider, select one from already prepared Providers.
|
||||
Sites could be configured differently per project basis.
|
||||
|
||||
#### Alternative sites
|
||||
Each new site needs to be created first in `System Settings`. Most important
|
||||
feature of site is its Provider, select one from already prepared Providers.
|
||||
|
||||
#### Alternative sites
|
||||
|
||||
This attribute is meant for special use cases only.
|
||||
|
||||
One of the use cases is sftp site vendoring (exposing) same data as regular site (studio). Each site is accessible for different audience. 'studio' for artists in a studio via shared disk, 'sftp' for externals via sftp server with mounted 'studio' drive.
|
||||
One of the use cases is sftp site vendoring (exposing) same data as regular
|
||||
site (studio). Each site is accessible for different audience. 'studio' for
|
||||
artists in a studio via shared disk, 'sftp' for externals via sftp server with
|
||||
mounted 'studio' drive.
|
||||
|
||||
Change of file status on one site actually means same change on 'alternate' site occurred too. (eg. artists publish to 'studio', 'sftp' is using
|
||||
same location >> file is accessible on 'sftp' site right away, no need to sync it anyhow.)
|
||||
Change of file status on one site actually means same change on 'alternate'
|
||||
site occurred too. (eg. artists publish to 'studio', 'sftp' is using
|
||||
same location >> file is accessible on 'sftp' site right away, no need to sync
|
||||
it anyhow.)
|
||||
|
||||
##### Example
|
||||
|
||||
|
||||
Admin created new `sftp` site which is handled by `SFTP` provider. Somewhere in the studio SFTP server is deployed on a machine that has access to `studio` drive.
|
||||
Admin created new `sftp` site which is handled by `SFTP` provider. Somewhere in
|
||||
the studio SFTP server is deployed on a machine that has access to `studio`
|
||||
drive.
|
||||
|
||||
Alternative sites work both way:
|
||||
|
||||
- everything published to `studio` is accessible on a `sftp` site too
|
||||
- everything published to `sftp` (most probably via artist's local disk - artists publishes locally, representation is marked to be synced to `sftp`. Immediately after it is synced, it is marked to be available on `studio` too for artists in the studio to use.)
|
||||
- everything published to `sftp` (most probably via artist's local disk -
|
||||
artists publishes locally, representation is marked to be synced to `sftp`.
|
||||
Immediately after it is synced, it is marked to be available on `studio` too
|
||||
for artists in the studio to use.)
|
||||
|
||||
## Project Settings
|
||||
|
||||
Sites need to be made available for each project. Of course this is possible to do on the default project as well, in which case all other projects will inherit these settings until overridden explicitly.
|
||||
Sites need to be made available for each project. Of course this is possible to
|
||||
do on the default project as well, in which case all other projects will
|
||||
inherit these settings until overridden explicitly.
|
||||
|
||||
You'll find the setting in **Settings/Project/Global/Site Sync**
|
||||
|
||||
The attributes that can be configured will vary between sites and their providers.
|
||||
The attributes that can be configured will vary between sites and their
|
||||
providers.
|
||||
|
||||
## Local settings
|
||||
|
||||
Each user should configure root folder for their 'local' site via **Local Settings** in OpenPype Tray. This folder will be used for all files that the user publishes or downloads while working on a project. Artist has the option to set the folder as "default"in which case it is used for all the projects, or it can be set on a project level individually.
|
||||
Each user should configure root folder for their 'local' site via **Local
|
||||
Settings** in OpenPype Tray. This folder will be used for all files that the
|
||||
user publishes or downloads while working on a project. Artist has the option
|
||||
to set the folder as "default"in which case it is used for all the projects, or
|
||||
it can be set on a project level individually.
|
||||
|
||||
Artists can also override which site they use as active and remote if need be.
|
||||
Artists can also override which site they use as active and remote if need be.
|
||||
|
||||
|
||||
|
||||
|
||||
## Providers
|
||||
|
||||
Each site implements a so called `provider` which handles most common operations (list files, copy files etc.) and provides interface with a particular type of storage. (disk, gdrive, aws, etc.)
|
||||
Multiple configured sites could share the same provider with different settings (multiple mounted disks - each disk can be a separate site, while
|
||||
Each site implements a so called `provider` which handles most common
|
||||
operations (list files, copy files etc.) and provides interface with a
|
||||
particular type of storage. (disk, gdrive, aws, etc.)
|
||||
Multiple configured sites could share the same provider with different
|
||||
settings (multiple mounted disks - each disk can be a separate site, while
|
||||
all share the same provider).
|
||||
|
||||
**Currently implemented providers:**
|
||||
|
|
@ -89,21 +121,30 @@ all share the same provider).
|
|||
|
||||
Handles files stored on disk storage.
|
||||
|
||||
Local drive provider is the most basic one that is used for accessing all standard hard disk storage scenarios. It will work with any storage that can be mounted on your system in a standard way. This could correspond to a physical external hard drive, network mounted storage, internal drive or even VPN connected network drive. It doesn't care about how the drive is mounted, but you must be able to point to it with a simple directory path.
|
||||
Local drive provider is the most basic one that is used for accessing all
|
||||
standard hard disk storage scenarios. It will work with any storage that can be
|
||||
mounted on your system in a standard way. This could correspond to a physical
|
||||
external hard drive, network mounted storage, internal drive or even VPN
|
||||
connected network drive. It doesn't care about how the drive is mounted, but
|
||||
you must be able to point to it with a simple directory path.
|
||||
|
||||
Default sites `local` and `studio` both use local drive provider.
|
||||
|
||||
|
||||
### Google Drive
|
||||
|
||||
Handles files on Google Drive (this). GDrive is provided as a production example for implementing other cloud providers
|
||||
Handles files on Google Drive (this). GDrive is provided as a production
|
||||
example for implementing other cloud providers
|
||||
|
||||
Let's imagine a small globally distributed studio which wants all published work for all their freelancers uploaded to Google Drive folder.
|
||||
Let's imagine a small globally distributed studio which wants all published
|
||||
work for all their freelancers uploaded to Google Drive folder.
|
||||
|
||||
For this use case admin needs to configure:
|
||||
- how many times it tries to synchronize file in case of some issue (network, permissions)
|
||||
|
||||
- how many times it tries to synchronize file in case of some issue (network,
|
||||
permissions)
|
||||
- how often should synchronization check for new assets
|
||||
- sites for synchronization - 'local' and 'gdrive' (this can be overridden in local settings)
|
||||
- sites for synchronization - 'local' and 'gdrive' (this can be overridden in
|
||||
local settings)
|
||||
- user credentials
|
||||
- root folder location on Google Drive side
|
||||
|
||||
|
|
@ -111,30 +152,43 @@ Configuration would look like this:
|
|||
|
||||
|
||||
|
||||
*Site Sync* for Google Drive works using its API: https://developers.google.com/drive/api/v3/about-sdk
|
||||
*Site Sync* for Google Drive works using its
|
||||
API: https://developers.google.com/drive/api/v3/about-sdk
|
||||
|
||||
To configure Google Drive side you would need to have access to Google Cloud Platform project: https://console.cloud.google.com/
|
||||
To configure Google Drive side you would need to have access to Google Cloud
|
||||
Platform project: https://console.cloud.google.com/
|
||||
|
||||
To get working connection to Google Drive there are some necessary steps:
|
||||
- first you need to enable GDrive API: https://developers.google.com/drive/api/v3/enable-drive-api
|
||||
- next you need to create user, choose **Service Account** (for basic configuration no roles for account are necessary)
|
||||
|
||||
- first you need to enable GDrive
|
||||
API: https://developers.google.com/drive/api/v3/enable-drive-api
|
||||
- next you need to create user, choose **Service Account** (for basic
|
||||
configuration no roles for account are necessary)
|
||||
- add new key for created account and download .json file with credentials
|
||||
- share destination folder on the Google Drive with created account (directly in GDrive web application)
|
||||
- add new site back in OpenPype Settings, name as you want, provider needs to be 'gdrive'
|
||||
- share destination folder on the Google Drive with created account (directly
|
||||
in GDrive web application)
|
||||
- add new site back in OpenPype Settings, name as you want, provider needs to
|
||||
be 'gdrive'
|
||||
- distribute credentials file via shared mounted disk location
|
||||
|
||||
:::note
|
||||
If you are using regular personal GDrive for testing don't forget adding `/My Drive` as the prefix in root configuration. Business accounts and share drives don't need this.
|
||||
If you are using regular personal GDrive for testing don't forget
|
||||
adding `/My Drive` as the prefix in root configuration. Business accounts and
|
||||
share drives don't need this.
|
||||
:::
|
||||
|
||||
### SFTP
|
||||
|
||||
SFTP provider is used to connect to SFTP server. Currently authentication with `user:password` or `user:ssh key` is implemented.
|
||||
Please provide only one combination, don't forget to provide password for ssh key if ssh key was created with a passphrase.
|
||||
SFTP provider is used to connect to SFTP server. Currently authentication
|
||||
with `user:password` or `user:ssh key` is implemented.
|
||||
Please provide only one combination, don't forget to provide password for ssh
|
||||
key if ssh key was created with a passphrase.
|
||||
|
||||
(SFTP connection could be a bit finicky, use FileZilla or WinSCP for testing connection, it will be mush faster.)
|
||||
(SFTP connection could be a bit finicky, use FileZilla or WinSCP for testing
|
||||
connection, it will be mush faster.)
|
||||
|
||||
Beware that ssh key expects OpenSSH format (`.pem`) not a Putty format (`.ppk`)!
|
||||
Beware that ssh key expects OpenSSH format (`.pem`) not a Putty
|
||||
format (`.ppk`)!
|
||||
|
||||
#### How to set SFTP site
|
||||
|
||||
|
|
@ -143,60 +197,101 @@ Beware that ssh key expects OpenSSH format (`.pem`) not a Putty format (`.ppk`)!
|
|||
|
||||
|
||||
|
||||
- In Projects setting enable Site Sync (on default project - all project will be synched, or on specific project)
|
||||
- Configure SFTP connection and destination folder on a SFTP server (in screenshot `/upload`)
|
||||
- In Projects setting enable Site Sync (on default project - all project will
|
||||
be synched, or on specific project)
|
||||
- Configure SFTP connection and destination folder on a SFTP server (in
|
||||
screenshot `/upload`)
|
||||
|
||||
|
||||
|
||||
- if you want to force syncing between local and sftp site for all users, use combination `active site: local`, `remote site: NAME_OF_SFTP_SITE`
|
||||
- if you want to allow only specific users to use SFTP syncing (external users, not located in the office), use `active site: studio`, `remote site: studio`.
|
||||
|
||||
- if you want to force syncing between local and sftp site for all users, use
|
||||
combination `active site: local`, `remote site: NAME_OF_SFTP_SITE`
|
||||
- if you want to allow only specific users to use SFTP syncing (external users,
|
||||
not located in the office), use `active site: studio`, `remote site: studio`.
|
||||
|
||||
|
||||
|
||||
- Each artist can decide and configure syncing from his/her local to SFTP via `Local Settings`
|
||||
- Each artist can decide and configure syncing from his/her local to SFTP
|
||||
via `Local Settings`
|
||||
|
||||
|
||||
|
||||
|
||||
### Custom providers
|
||||
|
||||
If a studio needs to use other services for cloud storage, or want to implement totally different storage providers, they can do so by writing their own provider plugin. We're working on a developer documentation, however, for now we recommend looking at `abstract_provider.py`and `gdrive.py` inside `openpype/modules/sync_server/providers` and using it as a template.
|
||||
If a studio needs to use other services for cloud storage, or want to implement
|
||||
totally different storage providers, they can do so by writing their own
|
||||
provider plugin. We're working on a developer documentation, however, for now
|
||||
we recommend looking at `abstract_provider.py`and `gdrive.py`
|
||||
inside `openpype/modules/sync_server/providers` and using it as a template.
|
||||
|
||||
### Running Site Sync in background
|
||||
|
||||
Site Sync server synchronizes new published files from artist machine into configured remote location by default.
|
||||
Site Sync server synchronizes new published files from artist machine into
|
||||
configured remote location by default.
|
||||
|
||||
There might be a use case where you need to synchronize between "non-artist" sites, for example between studio site and cloud. In this case
|
||||
you need to run Site Sync as a background process from a command line (via service etc) 24/7.
|
||||
There might be a use case where you need to synchronize between "non-artist"
|
||||
sites, for example between studio site and cloud. In this case
|
||||
you need to run Site Sync as a background process from a command line (via
|
||||
service etc) 24/7.
|
||||
|
||||
To configure all sites where all published files should be synced eventually you need to configure `project_settings/global/sync_server/config/always_accessible_on` property in Settings (per project) first.
|
||||
To configure all sites where all published files should be synced eventually
|
||||
you need to
|
||||
configure `project_settings/global/sync_server/config/always_accessible_on`
|
||||
property in Settings (per project) first.
|
||||
|
||||
|
||||
|
||||
This is an example of:
|
||||
|
||||
- Site Sync is enabled for a project
|
||||
- default active and remote sites are set to `studio` - eg. standard process: everyone is working in a studio, publishing to shared location etc.
|
||||
- (but this also allows any of the artists to work remotely, they would change their active site in their own Local Settings to `local` and configure local root.
|
||||
This would result in everything artist publishes is saved first onto his local folder AND synchronized to `studio` site eventually.)
|
||||
- default active and remote sites are set to `studio` - eg. standard process:
|
||||
everyone is working in a studio, publishing to shared location etc.
|
||||
- (but this also allows any of the artists to work remotely, they would change
|
||||
their active site in their own Local Settings to `local` and configure local
|
||||
root.
|
||||
This would result in everything artist publishes is saved first onto his
|
||||
local folder AND synchronized to `studio` site eventually.)
|
||||
- everything exported must also be eventually uploaded to `sftp` site
|
||||
|
||||
This eventual synchronization between `studio` and `sftp` sites must be physically handled by background process.
|
||||
This eventual synchronization between `studio` and `sftp` sites must be
|
||||
physically handled by background process.
|
||||
|
||||
As current implementation relies heavily on Settings and Local Settings, background process for a specific site ('studio' for example) must be configured via Tray first to `syncserver` command to work.
|
||||
As current implementation relies heavily on Settings and Local Settings,
|
||||
background process for a specific site ('studio' for example) must be
|
||||
configured via Tray first to `syncserver` command to work.
|
||||
|
||||
To do this:
|
||||
|
||||
- run OP `Tray` with environment variable OPENPYPE_LOCAL_ID set to name of active (source) site. In most use cases it would be studio (for cases of backups of everything published to studio site to different cloud site etc.)
|
||||
- run OP `Tray` with environment variable OPENPYPE_LOCAL_ID set to name of
|
||||
active (source) site. In most use cases it would be studio (for cases of
|
||||
backups of everything published to studio site to different cloud site etc.)
|
||||
- start `Tray`
|
||||
- check `Local ID` in information dialog after clicking on version number in the Tray
|
||||
- check `Local ID` in information dialog after clicking on version number in
|
||||
the Tray
|
||||
- open `Local Settings` in the `Tray`
|
||||
- configure for each project necessary active site and remote site
|
||||
- close `Tray`
|
||||
- run OP from a command line with `syncserver` and `--active_site` arguments
|
||||
|
||||
|
||||
This is an example how to trigger background syncing process where active (source) site is `studio`.
|
||||
(It is expected that OP is installed on a machine, `openpype_console` is on PATH. If not, add full path to executable.
|
||||
This is an example how to trigger background syncing process where active (
|
||||
source) site is `studio`.
|
||||
(It is expected that OP is installed on a machine, `openpype_console` is on
|
||||
PATH. If not, add full path to executable.
|
||||
)
|
||||
|
||||
```shell
|
||||
openpype_console syncserver --active_site studio
|
||||
```
|
||||
```
|
||||
|
||||
### Syncing of last published workfile
|
||||
|
||||
Some DCC might have enabled
|
||||
in `project_setting/global/tools/Workfiles/last_workfile_on_startup`, eg. open
|
||||
DCC with last opened workfile.
|
||||
|
||||
Flag `use_last_published_workfile` tells that last published workfile should be
|
||||
used if no workfile is present locally.
|
||||
This use case could happen if artists starts working on new task locally,
|
||||
doesn't have any workfile present. In that case last published will be
|
||||
synchronized locally and its version bumped by 1 (as workfile's version is
|
||||
always +1 from published version).
|
||||
Loading…
Add table
Add a link
Reference in a new issue