Use optional lifepoint headers to define object-specific Swarm replication and retention policies , which can be as simple or complex as with varying complexity as the situation requires.

See SCSP Headers.

Understanding Storage Policies

...

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.

Lifepoints to

...

Prevent Deletion

An important use of lifepoints is to protect objects from deletion. However, deleting Deleting a bucket containing such protected objects generates errors and orphans those named objects.

See "DELETE for domains and buckets" in  SCSP DELETE.

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

Lifepoint: [Wed, 12 Dec 2015 15:59:02 GMT] reps=3, deletable=no 
Lifepoint: [Sun, 08 Jun 2016 15:59:02 GMT] reps=2, deletable=yes 
Lifepoint: [] delete

Each time the Health Processor (HP) examines the object , it checks the current date to see determine how to apply the lifepoint policies:

Specifying Lifepoints and Lifecycles

Use a simple syntax to specify a complete object lifecycle, and specify one or more lifepoints. Attach lifepoint entity headers to an SCSP WRITE message.

...

lifepoint = "lifepoint" ":" end-date 1#constraint end-date = "[" [HTTP-date] "]" 
	constraint = replication-constraint | delete-constraint | deletable-constraint replication-constraint = 
		"reps" ["=" (1*DIGIT | 1*DIGIT:1*DIGIT)] delete-constraint = "delete" ["=" ("yes" | "no")] 
			deletable-constraint = "deletable" ["=" ("yes" | "no")]

Guidelines for

...

Lifepoints

Follow these guidelines when creating a lifepoint:

Lifepoint: [] reps=1,deletable=no

Lifepoint: [] reps=1
Lifepoint: [] deletable=no

Transfer-Encoding: chunked
Lifepoint: [Wed, 12 Dec 2016 15:59:02 GMT] reps=5:2 
Lifepoint: [] reps=3

Constraints for Replication and Deletion

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:

...

• Replicas – Place limits on the number of replicas that can be specified by defining policy.replicas min and max. 

• EC – Specify the ec.minParity to verify all objects have a minimum number of parity segments included for protection. Invalid or conflicting values of the reps constraint are ignored, defaults are used, and warnings are written to the log if found in a lifepoint. Lifepoints with erasure coding define what EC level to apply. For example: lifepoint = [] reps=5:2 expresses an erasure-coded level of 5 data segments and 2 parity segments.

Supported conversion methodsAs of v6.5, a Conversion Methods

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 

DeletionConstraintSpecialist

...

• The deletable constraint is set to yes|true or no|false:

  • yes|true (default) indicates the object is deletable by any client knowing the name or UUID. The DELETE method must also be included in the Allow header for a client delete to be allowed. 

  • no|false prevents 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.

Incorrect

...

Delete Constraint

Lifepoint: [Wed, 08 Jun 2012 15:59:02 GMT] reps=3, deletable=no, delete

Correct

...

Delete Constraint

Lifepoint: [Fri, 12 Dec 2011 15:59:02 GMT] reps=3, deletable=no 
Lifepoint: [] delete

...