-
Notifications
You must be signed in to change notification settings - Fork 66
-
Notifications
You must be signed in to change notification settings - Fork 66
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
Return status info from movers #538
Comments
Some info about current logging from movers Rclone: Example output from replication source mover (with no changes to rclone settings):
Here's output from a destination mover job:
Similar issue where all transfer speeds indicate 0 B/s. At least in both cases there's a summary at the end that shows total time. Edit: the actual summary is printed out by our wrapper script (active.sh) in the mover itself, not from rclone. volsync/mover-rclone/active.sh Line 41 in 5c2c92e
Update:
|
Related #554 |
Some restic info: Backup:
restore:
When turning up the verbosity there is an updating line that shows progress of the file in-transfer (similar to --progress with Rclone) and we do get a bit more info in the summary. Here's an example restic backup with
|
Example output from rsync: source:
destination:
|
Initial implementation is complete - closing this now - will open new issues if fine-tuning is required in the future. |
Describe the feature you'd like to have.
Today, there is relatively little information about what is happening during the sync process. We publish events for things like snapshots/clones, but once the Job starts, there is no available information until it completes. I'd like to be able to return status updates from the data movers so that the information can be exposed to end users without requiring them to
kubectl logs <volsync-mover-job>
.What is the value to the end user? (why is it a priority?)
It would be good for the mover jobs to be able to expose status information so that users can more easily see what the current status of synchronization is. Is it syncing? Is it failing to connect?
How will we know we have a good solution? (acceptance criteria)
Additional context
Updates we might want to publish:
Potential methods for returning information:
The text was updated successfully, but these errors were encountered: