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 filemanager should support a mechanism to transition objects to an expired state or a different storage class. This involves accepting a transition request via the API or the EventBus for a set of objects, and then performing the transition after the specified time period.
I think this can be accomplished with object tagging, and S3 lifecycle rules. For example, the filemanager could tag objects with predefined values matching lifecycle rules. This should only require one tag per transition. Moving should also not be an issue, because the filemanager can remove the lifecycle tag when an object is moved, as it's tracking moves via the filemanager_id tag.
A limitation of this approach is that it requires additional tags for each transition, and there is a maximum of 10 tags per objects. It doesn't look like there is a way to pack tag values into a single key to support multiple transitions, because the transition rules expect exact values for tags.
As an alternative, the filemanager could control the lifecycle transitions using it's own database state and DeleteObject. This could be more complicated but would remove the tag requirement, and allow supporting transitions using more complex logic like wildcards.
The text was updated successfully, but these errors were encountered:
It is possible to specify multiple transitions in a single lifecycle rule, so it should be possible to define rules that transition more than once based on a single tag. For example, a tag with the value standard_ia_30&glacier_90 could match a rule with a transition for standard_ia after 30 days and glacier after 90 days.
The filemanager should support a mechanism to transition objects to an expired state or a different storage class. This involves accepting a transition request via the API or the EventBus for a set of objects, and then performing the transition after the specified time period.
I think this can be accomplished with object tagging, and S3 lifecycle rules. For example, the filemanager could tag objects with predefined values matching lifecycle rules. This should only require one tag per transition. Moving should also not be an issue, because the filemanager can remove the lifecycle tag when an object is moved, as it's tracking moves via the
filemanager_id
tag.A limitation of this approach is that it requires additional tags for each transition, and there is a maximum of 10 tags per objects. It doesn't look like there is a way to pack tag values into a single key to support multiple transitions, because the transition rules expect exact values for tags.
As an alternative, the filemanager could control the lifecycle transitions using it's own database state and
DeleteObject
. This could be more complicated but would remove the tag requirement, and allow supporting transitions using more complex logic like wildcards.The text was updated successfully, but these errors were encountered: