...
Use optional lifepoint headers to define object-specific Swarm replication and retention policies , with varying complexity as the situation requires.
...
Specify a constraint when first storing the object in the storage cluster. For mutable or named objects, the The constraint can be changed with a COPY or a PUT for mutable or named objects.
Constraints can also be grouped together and 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.
...
Lifecycle evaluation example
Assume Consider an object was written to Swarm on June 12, 2015. In the first six months since creation, the The object must have at least three replicas and cannot be deleted by any user . In in the second first six months since creation, the . The object needs two replicas , and client applications can delete the object . After a year, the in the second six months since creation. The object is deleted after a year.
Complete lifecycle policy
...
Each time the Health Processor (HP) examines the object , it checks the current date to see determine how to apply the lifepoint policies:
...
Guideline | Explanation | |||||
|---|---|---|---|---|---|---|
Make every lifepoint stand alone | Lifepoints do not build upon one another: they . They stand alone as a complete specification of the constraints that apply to the object in a provided date range. Include the complete set of constraints for a provided end date in the lifepoint header. Correct lifepoint
| |||||
Provide time in GMT | For HTTP-date, adhere Adhere to the Full Date Section 3.3.1 of the HTTP/1.1 specification for HTTP-date. 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 | Swarm does not allow lifepoint-triggered deletes of contexts (domains and bucket objects) to protect content objects from being orphaned. See SCSP DELETE for guidance on deleting domains and buckets. | |||||
Do not replicate chunked uploads | Chunked uploads are erasure-coded automatically, so a . A request fails if it is chunked and the current lifepoint specifies replication. Specify two lifepoints to convert a chunked upload: have . 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 | Swarm does not validate lifepoints when they are added to the cluster to maximize performance. Swarm accepts an invalid lifepoint and later logs an error if the HP cannot parse the lifepoint. |
...
Constraint names and values are parsed by Swarm object classes called ConstraintSpecialists that maintain one or more related constraints. The reps constraint is parsed and maintained by the ReplicationConstraintSpecialist. Constraint names are case-sensitive , and constraint names not recognized by the ConstraintSpecialists are ignored. The set of allowable constraints is extensible , and new constraint types may be added to the system in future releases.
...
The ReplicationConstraintSpecialist maintains the desired level of redundancy of content objects and verifies they are stored in the most efficient manner. It understands one constraint name: , reps, which is set by protection type:
...
Supported conversion methods
As of v6.5, a A storage policy with multiple lifepoints including the following conversion methods are supported as of v6.5:
Replication to EC
EC to replication
One EC encoding to a different encoding
| Info |
|---|
ImportantThe object size value must be greater than the policy.ecMinStreamSize setting, regardless of the specified lifepoint. Otherwise, the The object is not erasure-coded and is instead protected with p+1 replicas otherwise. |
DeletionConstraintSpecialist
...
The deletable constraint is set to
yes|trueorno|false:yes|true(default) indicates the object is deletable by any client knowing the name or UUID. The DELETE method must be included in the Allow header for a client delete to be allowed.no|falseprevents any agent from deleting the object during the effective period of the lifepoint. Any attempt to delete the object result in a 403 (Forbidden) response.
The delete constraint does not accept a value. This constraint causes DeletionConstraintSpecialist to delete the content object from the cluster. The result is the same as if a client application had deleted the object.
To avoid ambiguity, when delete is present in a lifepoint specification, it Delete must be the sole constraint in that a lifepoint when present because other conditions on a deleted object may not be applicable. Additionally, a A delete lifepoint must be specified with an empty end date.
...