[WIP] Add support for S3 versioning #6494
Conversation
…d versioning info to (main) xl.json
Mint Automation
6494-3d931ad/mint-compression-fs.sh.log:6494-3d931ad/mint-dist-xl.sh.log:6494-3d931ad/mint-tls.sh.log:6494-3d931ad/mint-gateway-nas.sh.log:6494-3d931ad/mint-fs.sh.log:6494-3d931ad/mint-xl.sh.log:6494-3d931ad/mint-large-bucket.sh.log:6494-3d931ad/mint-compression-xl.sh.log: |
|
Hi, any updates on this PR? I think it's a very interesting feature. Thanks 😄 |
harshavardhana
force-pushed
the
master
branch
3 times, most recently
from
6d7e018
to
0146a9d
Compare
|
We are not planning to merge this into upstream just yet. |
|
Hi any date for the merge ? We start development on an new web app linked to minio but the object versioning is an feature mandatory and it is still missing. we planned to migrate to alfresco that provide this feature... But minio is amazing i hope a day this will be available. |
@blitz33 how do you name your objects? because usually the web apps store object with names such as "52de92f3-1518-4a7f-8c7f-2b2192f4ebd1/somename.jpg" i.e the object names are unique and do not overwrite previous objects hence there is no need for versioning. |
|
We will use our minio instance like an sharepoint representation in our custom web app with crud operation in the bucket. We will be able to get an button "historic" to view older versions of one file/object. The ability to get an older verdion of same file. I understand we can upload multiple versions of the same object on the same bucket but minio doesn t support list object versions. |
|
We would like to keep MinIO light on features and since versioning is not an often requested feature we are not planning to merge this PR. What applications typically do is create object names with unique names so that they don't overwrite previous objects and hence not need versioning. For example, in your case if you have a document "profile.doc", in your DB you can associate "profile.doc" with it's different versions like |
Bummer. Would you not even consider the versioning feature, if it became sponsored (paid) by one or more companies? I'm with a company that relies on Minio but the lack of versioning is slowly pushing me towards other solutions. No idea if I could actually convince my workplace to sponsor the feature implementation and continued maintenance/bugfixing long-term, but I could try. We're not a big company, however, so maybe other companies wanting this feature could chip in as well. Just a thought... |
|
@fdaone can you tell more about your use case? What is the application that you use on top of MinIO? Why is the application not able to create unique object names? |
|
@krishnasrinivas for us, the perspective that minio will have a version based object store is one of the main reasons we did not yet move on to a different solution. We currently use minion with Concourse-Ci which has massive advantages using a versioned object storage, especially in managing files. If you upload an artifact with a suffix as a version, you will have a nightmare deleting those later on - a big bummer after we migrated from amazon s3 to minio. The second case is somewhat similar to what i read here - we plan to use an object storage for our product https://drupal-wiki.com for attachments. Handling suffix based versions means we have to handle the whole versioning topic in our application as we already do (with fs based storage) and that is the exact reason we are migrating to an object based storage. There are alternatives to minio and they went on our radar straight away after reading your statement. |
|
@EugenMayer if versioning is a strict requirement it is better to use alternatives at this point. @krishnasrinivas already explained why it's not implemented. Application level logic is the best bet in this scenario from where we see it. |
|
@hackintoshrao fair enough - i understood and i am glad to see you being straight and open. Sadly this means for me migrating to a different storage on all levels ;\ |
It is several different applications. "Standard" applications as well as stuff developed in-house. For us, it would be ten times easier to have the object store handle versioning instead of implementing it within all the different applications. Plus, for some 3rd party applications it is unlikely it will be a priority of the software supplier to implement a form of versioning at the app level. |
|
I understand wanting to keep minio light... but at the same time, I can already think of maybe 10 diff ways I could use this. Additionally, while this all could be a matter of data modeling... I'd honestly rather have that be 1) compatible with s3, and 2) handled in a standard way. I'd vote for the feature to be added, if this was something that was actually up for a vote. |
@ronnyek thanks for your interest - there are some explanations on why it's not required in almost all situations #6494 (comment) |
|
Closing this PR as stale @fwessels - we shall re-open if needed in future. |
you can, but the need to version a file arises, for example, when you have to keep the same url address in case of different versions. |
|
any updates on this PR? |
We are not implementing this for now. |
This PR will add support for versioning. A bucket can be enabled for versioning after which all previous versions of an object will be retained (each with their own unique version-id). A delete of an object will not actually delete the contents of an object but put a so called Delete Marker on top. Individual versions of an object can be deleted so it is possible to go back to previous versions.
Support for list-object-versions is added, so all versions (and delete markers) of an object are listed.
Limitations
How Has This Been Tested?
For now testing using the AWS SDK, to be revisited.
Types of changes
Checklist: