...
Constraints can also be grouped together and given provided an expiration date. This type of constraint group is called a lifepoint because it represents a point where the health requirements of an object change. A sequence of lifepoints are collectively called a storage policy or a content lifecycle.
...
Guideline | Explanation | |||||
|---|---|---|---|---|---|---|
Make every lifepoint stand alone | Lifepoints do not build upon one another: they stand alone as a complete specification of the constraints that apply to the object in a given provided date range. Include the complete set of constraints for a given provided end date in the lifepoint header. Correct lifepoint
| |||||
Give Provide time in GMT | For HTTP-date, adhere to the Full Date Section 3.3.1 of the HTTP/1.1 specification. This means the indicated time must be specified in Greenwich Mean Time (GMT). GMT is exactly equal to UTC (Coordinated Universal Time) when dealing with Swarm. | |||||
Do not use deletable= without reps= | The delete constraint does not store a value and cannot include end-date : Incorrect delete constraint
| |||||
Do not delete contexts by lifepoint | To protect content objects from being orphaned, Swarm does not allow lifepoint-triggered deletes of contexts (domains and bucket objects). See SCSP DELETE for guidance on deleting domains and buckets. | |||||
Do not replicate chunked uploads | Chunked uploads are erasure-coded automatically, so a request fails if it is chunked and the current lifepoint specifies replication. To convert a chunked upload, specify two lifepoints: have the first specify an EC encoding expiring in one day, and have the second specify the number of replicas going forward: Converting chunked to replication
| |||||
Do not expect Swarm to validate lifepoints | To maximize performance, Swarm does not validate lifepoints when they are added to the cluster. Swarm accepts an invalid lifepoint and later logs an error if the HP cannot parse the lifepoint. |
...