-
Notifications
You must be signed in to change notification settings - Fork 64
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
First time Replication Destinations fail in v0.8.1, succeed in v0.8.0 #1172
Comments
In case it helps, the replication endpoint is the latest release of minio. |
See #1163 as well |
In this case I can definitely reproduce it on demand. If there's any additional information I can gather please let me know 👍 |
There was a fix in v0.8.1 (#1005) for a bug where if the auth or connection to the data store hosting the restic backup failed, the replicationdestination would succeed and not throw any errors. If you are trying to restore a backup from a bucket that cannot authenticate or does not exist, then you will get an error. Generally this is desired as we want to know if a restore from a backup does not succeed. |
Would it be possible to allow an override in the install to not error? I have a GitOps set up, so having the destination on all pvc definitions makes life a lot easier, including new ones. I would imagine that's what others are doing as well. |
Wait. Is it if a bucket doesn't exist or a path? In my case a bucket did and a path did not. |
I am using one bucket with sub-folders per |
@onedr0p and @no1here0003 Yes you're correct, it wouldn't just be the bucket, but the path itself. Essentially it means that path cannot be found and/or is not initialized as a restic repo. Potentially we could look at trying to initialize the path if doing restic operations such as listing snapshots on it fails (initing the path would then fail if the path has already been initialized so I think that would be pretty safe) - however the issue with ignoring errors when the path doesn't exist is it means a restore from a backup may look like it succeeds even if your data was blown away. Generally I would prefer to prioritize an actual restore from a backup and know the status of this restore than for an initial setup type situation where the bucket or path does not exist. I think I understand your scenario better now however, so will discuss and get back to you. |
An update: I've discussed with @JohnStrunk and I think we're going to put in a fix to try and make a restore from empty (or no path) not throw an error, which should then restore the behaviour you're used to, but still fail the job if the credentials are incorrect or cannot connect. The fix would be this on restore:
I think this should solve most issues and will allow you to restore from empty/non existing repos. The side effect will be that it will init the path ahead of your replicationsource doing it (I don't believe this should cause any issue). I'm going to try to get this fix into the v0.9.1 release. Just FYI we have a v0.9.0 release that may come out as soon as tomorrow - but this will not contain the fix yet. |
Thanks for the update @tesshuflower that seems like a great solution indeed. |
Awesome, thank you very much! |
Fixes: backube#1172 Signed-off-by: Tesshu Flower <tflower@redhat.com>
Describe the bug
Creating a brand new replicationdestination in VolSync v0.8.1 fails with:
v0.8.0 works.
Steps to reproduce
Create a new replication destination in a bucket that it has never been in before as a first time deployment in version v0.8.1, the jobs error and the pvc associated with it is stuck in Pending.
Do the same in v.0.8.0 and it works.
Expected behavior
It should behave as v0.8.0 did
Actual results
PVC is stuck in pending and VolSync jobs error with the above error message.
Additional context
This was a first time install of VolSync, I went straight to v0.8.1 and this happened. Downgrading to v0.8.0 worked.
The text was updated successfully, but these errors were encountered: