Issues discovered in testing
Issues discovered in testing:
Re the orphaned chunk issue ( - DURACLOUD-1155Getting issue details... STATUS ), it appears that orphanned chunks are not removed when the file that is being updated is identical to the one in duracloud. There is one way around it: jumpstart mode. When the synctool is in jumpstart mode, the file is retransferred and the chunks are removed.
So the scenario we are talking about is as follows:
We have a tool for identifying orphanned chunks and removing them which we have used successfully in the recent past. We could force the synctool to perform a cleanup when it detects matching files. Or we could support that feature when a flag is enabled. Or it would also be possible to prevent the cleanup, when a flag is present.
As far as duracloud operations are concerned, making cleanup on matching files the default behavior and providing a flag to suppress it for power users is optimal since we won't have to worry about scrubbing spaces after users upgrade to 6.1.0.
For the users, the best option is for us not to implement "cleanup on checksum match" behavior at all and scrub their repositories once they upgrade to the new synctool.
Thanks for calling this out Danny. I know that the scenario you're calling out has occurred, but it is definitely an edge case. Considering that we have other tooling to discover and clean up this issue directly I don't think it's necessary to burden the SyncTool process with checking for orphaned files on each file it touches. That has the potential to significantly slow down the sync process, especially if many small files are being transferred.
I'll make the call to leave the SyncTool as-is for 6.1. We will definitely want to encourage all users to upgrade to the new SyncTool as soon as it is available.
Resolved in PR: https://github.com/duracloud/duracloud/pull/107
|I had this happen to me while I was testing multi-space delete in the last few days.|
When deleting more than 2 spaces as a root user, the "are you sure" dialog appears (and require a confirmation click) 1 time less than the number of spaces being deleted. So if attempting to delete 5 spaces, you need to click "ok" 4 times.
Resolved in PR: https://github.com/duracloud/duracloud/pull/106
|I'm seeing this behavior now, too. Looking into it.|
Testing of Completed Issues
|Perform Regression Tests|
|Use ZAProxy to perform a security analysis||duracloud-6.1.0-zaproxy-report.html|
|mvn clean install (full build + integration tests) - DuraCloud|
Integration tests fail frequently due to a "space already exists" error. See issue #2.
After all updates applied
(Two tests failed, but upon further investigation it was clear that they were false positives)
Release Actions - for each baseline (in this order): DB, DuraCloud, MC, Snapshot, Mill
- Complete testing
- Perform version release (v6.1.0): https://github.com/duracloud/deployment-docs/blob/master/release-new-version.md
- Deploy release zip to production Beanstalk
- Create release notes in Github
- Update documentation
- Update download links to point to Github release