Design and apply precise policies for where and how to apply protections in the implementation to make the fullest use of the rich content protection features of Swarm. Policies define how the data being uploaded to the Swarm cluster is stored, managed, and protected. 

How it Works

Cluster-level policies reside in configuration settings and allow defining cluster-wide and cluster-specific policies for how Swarm implements the content protection features (See https://perifery.atlassian.net/wiki/spaces/public/pages/2443811617). These baseline cluster policies can be layered with context-level (domain and bucket) policies, which reside in designated headers in the context objects themselves. Policies are not lifepoints (https://perifery.atlassian.net/wiki/spaces/public/pages/2443821972): They do not have built-in lifetimes, nor do they specify transitions from one policy to another over time. Policies are only changed by explicit updates.

Types of Content Policies

Policies can be set for these content protection options, specific to the context needed:

1. https://perifery.atlassian.net/wiki/spaces/public/pages/2443812060 - How many default, minimum, and maximum number of replicas to keep for the objects in this cluster/domain/bucket

2. - Whether to enable or specify the EC encoding (k:p) to use for the objects in this cluster/domain/bucket

3. - Whether to enable, disable, or suspend versioning for the objects in this cluster/domain/bucket

These appear under the bucket or domain's Properties (gear) tab, Storage Policies section in the Content UI:

Open

How Policies Resolve

Swarm begins policy evaluation by eliminating contexts (domain and bucket) not applicable to resolving overlapping policies for one of two reasons:

• because of the "anchored" parameter, which overrides lower-level policies

• because of the type of object, which restricts it to certain contexts:

  Open

  

Swarm (1) selects the anchored policy if it exists, or else (2) checks the relevant contexts from the bottom up and selects the first policy it finds.

Setting Policies by Cluster

Cluster-specific policies for domains and buckets can be set by including the cluster name parenthetically and separating them with a comma. Swarm looks for and takes any cluster-specific policy values, using the default value only if it finds no match.

A policy (such as versioning) may be desired to be enabled in the main cluster but disabled in the target of the replication feed. This is how a feature is enabled in the main cluster (myCluster) but disabled in the one-way replication cluster (myRemote):

Updating Policies

Swarm cluster policies are all , so use the snmpset command on the cluster's settings object to change and persist the policies cluster-wide. Domain and bucket policies are saved as headers on those objects.

See .