Skip to content

Latest commit

 

History

History
39 lines (17 loc) · 2.28 KB

20210731-email.md

File metadata and controls

39 lines (17 loc) · 2.28 KB

Hi everyone,

Apparently it's Saturday night - so just ignore that if that's important to you.

This email is to start a discussion about the most sustainable, robust way for iRODS to present as S3 into the future. Many projects and organizations now have an S3-friendly outlook, but are interested in cheaper / local / flexible options that are not from Amazon itself.

Below are some scenarios, please look through them and we can decide what makes the most sense to the most of us. Please forward / include anyone else who may have insight or should have a vote in the matter.

  1. Update and maintain https://github.com/bioteam/minio-irods-gateway

This minio-based front end already exists and has been demonstrated, but has not been updated since its debut. I do not know the extent that it has been used in production work, perhaps John can talk about that. This uses the GoRODS client library, which will continue to need to be updated to wrap the latest iRODS C API as new releases of the server come out. Presumably, BioTeam / John would continue to own/maintain GoRODS and the minio-irods-gateway.

  1. minio-irods-gateway converts to use https://github.com/cyverse/go-irodsclient

Illyoung has produced and is actively developing a pure Go iRODS client library. This new library could be 'swapped' for the GoRODS calls in the minio-irods-gateway. Presumably, then Arizona / Illyoung would own/maintain a fork of the minio-irods-gateway.

  1. Add irods/gateway-irods.go to upstream https://github.com/minio/minio/tree/master/cmd/gateway

Someone / all of us would port / implement the same work from Option 2 (convert to pure Go), but work with the minio community to get iRODS to be an officially supported gateway for the MinIO server directly.

  1. New C++ implementation - https://github.com/irods/irods_client_s3_cpp

The iRODS Consortium would work to implement the S3 specification directly with a new C++ client. This could be more performant (in the long run), but requires the most work and answers to open questions.

I am leaning towards Option 3 as the best option both from a cost/benefit perspective, as well as exposure to a larger community and confidence that 'it just works'.

Happy to hear your opinions on these options (or others), and of course, entertain offers to help :)

Thanks,

Terrell