You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The good news is that it worked perfectly using the S3 protocol handler, I'm planning on testing the Swift interface too, and I've let our services team and other practitioners know, and I've suggested that they use Mountain Duck as a trouble shooting / testing tool.
I know you've probably got higher priority items than verifying functionality against every S3/Swift compliant object store out there, but if you want to do some interoperability testing of your own, NetApp can give you any documentation you might want and a repository for you to test against.
Personally I'd like to see the interoperability confirmed from both sides, because that would make it easier for me to recommend mountain-duck to our enterprise clients as a client based filesystem client (as opposed to using a CIFS / NFS gateway) that has a well defined support infrastructure.
Regards
John Martin
Director Strategy and Technology - APAC
NetApp.
The text was updated successfully, but these errors were encountered:
Thanks for your testing. You might be interested to share a connection profile for your customers with some more predefined settings for a bookmark. I have added NetApp to the list of thirdparty S3 providers. If required on can dedicate a wiki page to interoperability with NetApp StorageGrid Webscale.
Thanks,
I've begun the process with our product development and QA team, and I've added it to one of my personal projects without a specific completion date. Once I've had more feedback from product operations, or have an ETD for doing something myself, I'll update that in the comments here.
There was another group of interoperability questions with Cyberduck that are being discussed internally that we've discovered during some large scale proof of concept work around things like large multi-part upload timeouts and object vs bucket ACLs.
Would it be correct to assume that Cyberduck and Mountainduck use the same access engine ? If so, does it make sense to add those questions to this ticket, or to open seperate tickets for each question ?
Mountain Duck uses the same core modules with the protocol implementations. Please open a separate ticket for each issue. If more like a question or something to discuss you can also write to [mailto:support@cyberduck.io].
Dear mountain duck developers .. I've just tested mountain duck against the NetApp StorageGrid Webscale product http://www.netapp.com/us/products/object-storage/storagegrid/index.aspx
The good news is that it worked perfectly using the S3 protocol handler, I'm planning on testing the Swift interface too, and I've let our services team and other practitioners know, and I've suggested that they use Mountain Duck as a trouble shooting / testing tool.
I know you've probably got higher priority items than verifying functionality against every S3/Swift compliant object store out there, but if you want to do some interoperability testing of your own, NetApp can give you any documentation you might want and a repository for you to test against.
Personally I'd like to see the interoperability confirmed from both sides, because that would make it easier for me to recommend mountain-duck to our enterprise clients as a client based filesystem client (as opposed to using a CIFS / NFS gateway) that has a well defined support infrastructure.
Regards
John Martin
Director Strategy and Technology - APAC
NetApp.
The text was updated successfully, but these errors were encountered: