... | ... | @@ -26,7 +26,8 @@ to apply the condition only to the collections created inside a specific path. |
|
|
A list of triggered conditions (called static Policy Enforcement Points, PEP) is available in the Appendix A at page 215 and in the Appendix B at page 217 of the [workbook][3]. Another one is in the [iRODS manual][4].
|
|
|
|
|
|
## Examples
|
|
|
Let's now consider an important data policy: the uploaded data is immutable. And the opposite one: the uploaded data is mutable. If the uploaded data is immutable what it is needed to enforce such policy?
|
|
|
Let's now consider an important data policy: the uploaded data is immutable. And the opposite one: the uploaded data is mutable. If the uploaded data is immutable what it is needed to enforce such policy?
|
|
|
### Immutable data policy
|
|
|
This kind of policy is usually agreed with the data owners, for example a scientific community. Therefore the B2SAFE administrator can rely on the fact that the scientific community will not break the policy and just set the following trigger in the iRODS core.re to create a PID for each uploaded object:
|
|
|
```
|
|
|
acPostProcForPut
|
... | ... | @@ -81,7 +82,47 @@ dataArchiveCopy(*collPath, *archivePath) { |
|
|
}
|
|
|
}
|
|
|
```
|
|
|
|
|
|
The above rule should be executed periodically by the B2SAFE administrator.
|
|
|
The first approach could work for few collections, but it would not scale for many collections and multiple communities. The latter is more general, but it requires more care during its configuration.
|
|
|
### Mutable data policy
|
|
|
What happens, at the opposite, if the community asks to keep open the data set for future changes?
|
|
|
Assuming the data have PIDs and are replicated across different iRODS zones, the update of an object implies to propagate the changes both to the PID record's attributes and to the object's replicas. Does B2SAFE supports such propagation? It does, in the sense that it provides the means to define a workflow to manage those updates.
|
|
|
For example, in the case of the PID record, if you overwrite an object, you need to update the checksum. Then the B2SAFE administrator can configure the following trigger:
|
|
|
```
|
|
|
acPostProcForModifyDataObjMeta
|
|
|
{
|
|
|
ON($objPath like "/MyZone/home/community/*")
|
|
|
{
|
|
|
getEpicApiParameters(*credStoreType, *credStorePath, *epicApi, *serverID, *epicDebug);
|
|
|
EUDATSearchPID($objPath, *existing_pid);
|
|
|
EUDATeCHECKSUMupdate(*existing_pid, $objPath);
|
|
|
writeLine("serverLog","checksum updated for object: $objPath");
|
|
|
}
|
|
|
}
|
|
|
```
|
|
|
And in the case of the object's replica, she can add this code to the same trigger:
|
|
|
```
|
|
|
[...]
|
|
|
*replicaList = list();
|
|
|
EUDATgetLastAVU($objPath, "EUDAT/REPLICA", *replicas);
|
|
|
if ((*replicas != "") && (*replica != "None")) {
|
|
|
*replicaList = split(*replicas, ",");
|
|
|
foreach (*replica in *replicaList) {
|
|
|
EUDATeURLsearch(*replica, *URL);
|
|
|
*hostAndPath = elem(split(*URL, "://"), 1);
|
|
|
*replicaPath = "/" ++ triml(*hostAndPath, "/");
|
|
|
msiDataObjUnlink(*replicaPath, *out);
|
|
|
*registered = "true";
|
|
|
*recursive = "true";
|
|
|
EUDATReplication($objPath, *replicaPath, *registered, *recursive, *response);
|
|
|
writeLine("serverLog","Updated replica *replicaPath for object $objPath: *response");
|
|
|
}
|
|
|
}
|
|
|
[...]
|
|
|
```
|
|
|
If the B2SAFE administrator needs to change the local path of a collection, it can define similar triggers with other B2SAFE rules: _EUDATeURLupdate(*PID, *newURL)_ to update the URL of a PID record or _EUDATeURLupdateColl(*PID, *newURL)_ to update recursively the URL of a collection and of all the objects and sub-collections under the main one.
|
|
|
***
|
|
|
Those are examples of possible solutions to implement the most common data policies. They are not granted to work as they are, they could require to be adapted to the specific B2SAFE environment. But they intend to show that B2SAFE provides the building blocks to support the various data workflows and it is flexible enough to meet different scenarios.
|
|
|
|
|
|
[1]: https://github.com/EUDAT-B2SAFE/B2SAFE-core/wiki/Workflows "workflows"
|
|
|
[2]: https://github.com/EUDAT-B2SAFE/B2SAFE-core/blob/master/rulebase/pid-service.re "pid ruleset"
|
... | ... | |