Around OCI Object Storage : The lifecycle Management

So this post is the continuity of the previous one , where I described the concepts around OCI Object Storage.

Once the bucket is created, the datas within the object storage is managed through a lifecycle policy rules that define the lifecycle for those datas within a bucket. Either through an automated archiving rule or a deletion rule or other rule that you define and schedule.

The goal of the object lifecycle Mgt is to reduce the storage costs and saving time.

The supported resources are : Objects || Object previous versions || Uncommitted Multipart Uploads.

The supported lifecycle actions by default are : Move to Infrequent Access (not available if the auto-tiering is enabled) || Move to Archive || Delete .

The object name filters are optional, but useful to define the scope of the lifecycle policy rules. So, the Object name filters can have an object prefix or pattern watching condition.

What is the difference ?

Pattern matching : – Matching happens on the entire object name – It’s support wildcard characters -For example: *png match all the objects with *png in the whole bucket.

Prefix matching : – Not support wildcard characters. _ Exact matching of the left-most characters of the object name – For example: Prefix filter value is /oci/testA/ => that will cover all the objects within /oci/testA/

Question : is there any priority of the evaluation of those filters ?

Answer : Yes. First one, » Exclude by pattern ».Second , « Include by pattern » .Last one , « Include by prefix ».

Notice that you can create around 1000 lifecycle policy rules per bucket.