{"id":20358171,"url":"https://github.com/irods/irods_rule_engine_plugins_policy","last_synced_at":"2025-03-04T17:48:09.938Z","repository":{"id":66171961,"uuid":"234619979","full_name":"irods/irods_rule_engine_plugins_policy","owner":"irods","description":null,"archived":false,"fork":false,"pushed_at":"2023-07-13T20:28:04.000Z","size":460,"stargazers_count":1,"open_issues_count":1,"forks_count":2,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-01-15T01:42:35.809Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/irods.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-01-17T19:18:05.000Z","updated_at":"2023-09-01T19:30:38.000Z","dependencies_parsed_at":null,"dependency_job_id":"b1bcbe32-8b7a-44b4-bf04-8504feee2c99","html_url":"https://github.com/irods/irods_rule_engine_plugins_policy","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rule_engine_plugins_policy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rule_engine_plugins_policy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rule_engine_plugins_policy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/irods%2Firods_rule_engine_plugins_policy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/irods","download_url":"https://codeload.github.com/irods/irods_rule_engine_plugins_policy/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241895344,"owners_count":20038512,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-14T23:25:40.574Z","updated_at":"2025-03-04T17:48:09.911Z","avatar_url":"https://github.com/irods.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# iRODS Rule Engine Plugins - Policy\n\n## Motivation\n\nThe process for creating and deploying policy for iRODS requires the rule author to have a complete understanding of the API for iRODS as well as the associated plugin architecture in order to properly leverage the dynamic policy enforcement.  The author may need to invoke the same policy across several policy enforcement points in order to cover all possible means to move data into iRODS for both object and POSIX data movement.  The goal of this framework is to streamline the crafting and deployment of policy, as well as provide a reusable body of policy that may be easily configured.\n\nPolicy should be a matter of configuration rather than hand-crafted code.  For most use cases, it should be able to follow a well-documented deployment pattern already in use by others.\n\n![policy_graphic](policylayer_graphic_uniq.png)\n\n## The Policy Interface\n\nAll policy (rules) to be invoked by this system must conform to a simple interface of two parameters (both serialized JSON strings) known as the `parameters` and the `configuration`.  This policy may be implemented in any rule language or as a simple rule engine plugin.\n\nFor example, in the iRODS Rule Language\n```c++\nirods_policy_example_policy_implementation(*parameters, *configuration) {\n    writeLine(\"stdout\", \"Hello, World!\")\n}\n```\n\nOr in Python, to be used by the Python Rule Engine Plugin:\n```python\ndef irods_policy_example_policy_implementation(rule_args, callback, rei):\n# Parameters    rule_args[1]\n# Configuration rule_args[2]\n```\n\nThe `parameters` contain all the information captured by the event handler, or may be passed in as a prepopulated JSON object when configured.  These values may change depending on how the policy is configured and the contract between the policy and the event handlers used.  The `configuration` may contain any other pertinent information that the policy may need at the time of invocation.  This is a way to externalize any variables the policy may leverage, such as a specific attribute to use for metadata application.\n\nPolicy may be invoked directly, by an event handler or by the Query Processor.  This will be discussed later.\n\n## Event Handlers\n\nEvent handlers are a classification of rule engine plugin which consume dynamic policy enforcement points related to a noun within iRODS and invoke policy configured for events generated by the plugin.  There exists one event handler per noun in the system.\n\nThe complete list is:\n  * Data Objects\n  * Collections\n  * Metadata\n  * Resources\n  * Users and Groups\n\nThe policy to be invoked is a matter of the plugin-specific configuration within `/etc/irods/server_config.json` for a given instance of an event handler.  The `\"plugin_specific_configuration\"` object for the given instance will look for a JSON array `\"policies_to_invoke\"`, which itself is a series of JSON objects.  These objects are the configuration of a policy to invoke for a given series of events.\n\nThe policy objects contain:\n  * conditional\n  * active_policy_clauses\n  * events\n  * policy_to_invoke\n\n### Conditional\n\nA conditional describes a set of conditions which must be met in order to invoke the policy.  These are a series of regular expressions which match the nouns involved.  This could be the `logical_path`, `metadata_applied`, `metadata_exists`, `user_name`, `source_resource`, or `destination_resource`.  The metadata conditionals are separated into two flavors, one for the application of metadata and one for invoking policy based on the existence of metadata.  The `metadata_exists` conditional will test for the existence of matching metadata on any `entity_type` configured.  The `\"entity_type\"` for the metadata maps to the iRODS nouns which are: `\"data_object\", \"collection\", \"resource\", and \"user\"`.  To match metadata that may exist anywhere in a logical path, a `recursive` flag may be set to walk the path looking for matching metadata.\n\nAn example might be:\n```json\n\"conditional\" : {\n    \"logical_path\" : \"/tempZone/home/*\",\n    \"metadata_applied\" : {\n        \"attribute\" : \"foo*\",\n        \"value\" : \"bar*\",\n        \"units\" : \"baz*\",\n        \"entity_type\" : \"data_object\"\n    }\n}\n```\n\nAn example for matching metadata in a logical path used to invoke an indexing event:\n```json\n\"conditional\" : {\n    \"logical_path\" : \"/tempZone/home/*\",\n    \"metadata_exists\" : {\n        \"recursive\" : \"true\",\n        \"attribute\" : \"irods::indexing::index\",\n        \"value\" : \"elasticsearch::full_text\",\n        \"entity_type\" : \"data_object\"\n    }\n}\n```\n\nAn example matching data objects put into a destination root resource:\n```json\n\"conditional\" : {\n    \"logical_path\" : \"/tempZone/home/*\",\n    \"destination_resource \" : \"dest_resc_*\"\n}\n```\n\n### Active Policy Clauses\n\n`\"active_policy_clauses\"` is a JSON array of one or more of the following strings: `\"pre\", \"post\", \"except\", \"finally\"`.  These map to which dynamic policy enforcement points are invoked at which point in the operation flow.\n\nFor example: `\"active_policy_clauses\" : [\"post\"],`\n\nThe policy clauses map directly to the policy enforcement point flow control, where a policy may be invoked at any of these points in the flow for any event configured.\n\n\u003cimg src=\"pep_flow_control.png\" width=250 alight=right\u003e\n\n### Events\n\n`\"events\"` is a JSON array of strings which map to the events generated by the event handler. Each event handler will have its own set of events for which it may invoke policy which are documented below.\n\nFor a data-object-modified example where data is ingested: `\"events\" : [\"create\", \"write\", \"registration\"],`\n\n### Policy to Invoke\n\n`\"policy_to_invoke\"` is a JSON string which is the name of the policy to invoke.  Following the policy is a `\"configuration\"` object which contains any specific information related to that given policy.\n\nAn example for data replication:\n```\n\"policy_to_invoke\" : \"irods_policy_data_replication\",\n\"configuration\" : {\n    \"source_to_destination_map\" : {\n        \"edge_resource_0\" : [\"long_term_resource_0\"],\n        \"edge_resource_1\" : [\"long_term_resource_1\"],\n}\n```\n\n## Data Object Modified Event Handler\n\nThe Data Object Modified event handler unifies both the Object and POSIX semantics, as well as other iRODS specific operations such as registration, into a single point of truth for invoking policy related to data access.  The plugin maps policy enforcement points to specific set of events for which policy may be configured.  The event handler provides events for all operations related to data objects:\n\n* CHECKSUM\n* COPY\n* CREATE\n* GET\n* PUT\n* REGISTER\n* RENAME\n* REPLICATION\n* SEEK\n* TRIM\n* TRUNCATE\n* UNLINK\n\nThe data object modified event handler captures all variables within the `dataObjInp_t` and `rsComm_t` which are then seralized to JSON and passed to the invoked policy.  Additional information such as the event and associated policy enforcement point are also included.\n\n```json\n{\n\"comm\":{\n    \"auth_scheme\":\"native\",\"client_addr\":\"X.X.X.X\",\"proxy_auth_info_auth_flag\":\"5\",\"proxy_auth_info_auth_scheme\":\"\",\n    \"proxy_auth_info_auth_str\":\"\",\"proxy_auth_info_flag\":\"0\",\"proxy_auth_info_host\":\"\",\"proxy_auth_info_ppid\":\"0\",\n    \"proxy_rods_zone\":\"tempZone\",\"proxy_sys_uid\":\"0\",\"proxy_user_name\":\"rods\",\"proxy_user_other_info_user_comments\":\"\",\n    \"proxy_user_other_info_user_create\":\"\",\"proxy_user_other_info_user_info\":\"\",\"proxy_user_other_info_user_modify\":\"\",\n    \"proxy_user_type\":\"\",\"user_auth_info_auth_flag\":\"5\",\"user_auth_info_auth_scheme\":\"\",\"user_auth_info_auth_str\":\"\",\n    \"user_auth_info_flag\":\"0\",\"user_auth_info_host\":\"\",\"user_auth_info_ppid\":\"0\",\"user_rods_zone\":\"tempZone\",\n    \"user_sys_uid\":\"0\",\"user_user_name\":\"rods\",\"user_user_other_info_user_comments\":\"\",\"user_user_other_info_user_create\":\"\",\n    \"user_user_other_info_user_info\":\"\",\"user_user_other_info_user_modify\":\"\",\"user_user_type\":\"\"\n    },\n\"cond_input\":{\n    \"dataIncluded\":\"\",\"dataType\":\"generic\",\"destRescName\":\"ufs0\",\"noOpenFlag\":\"\",\"openType\":\"1\",\n    \"recursiveOpr\":\"1\", \"resc_hier\":\"ufs0\",\"selObjType\":\"dataObj\",\"translatedPath\":\"\"\n    },\n\"create_mode\":\"33204\",\n\"data_size\":\"1\",\n\"event\":\"CREATE\",\n\"num_threads\":\"0\",\n\"obj_path\":\"/tempZone/home/rods/test_put_gt_max_sql_rows/junk0083\",\n\"offset\":\"0\",\n\"open_flags\":\"2\",\n\"opr_type\":\"1\",\n\"policy_enforcement_point\":\"pep_api_data_obj_put_post\"\n}\n```\n\n## Metadata Modified Event Handler\n\nThe metadata modifed event handler reacts to the interaction of a client with the user defined metadata within the catalog and generates one event: `METADATA`.\n\nIt provides a parameter object of the following form:\n\n```json\n{\n    \"metadata\" : {\n        \"operation\"   : \"\",\n        \"entity_type\" : \"\",\n        \"attribute\"   : \"\",\n        \"value\"       : \"\",\n        \"units\"       : \"\"\n    },\n    \"logical_path\" : \"\",\n    \"source_resource\" : \"\",\n    \"user_name\" : \"\"\n}\n```\n\n`operation` may be one of the following: `set`, `add`, or `remove`.\n\n`entity_type` may be one of `data_object`, `collection`, `resource`, or `user`.\n\n`logical_path`, `source_resource`, and `user_name` are optional depending on the target of the metadata operation.\n\n\n## Collection Event Handler\n\nThe collection event handler emits three operations: `CREATE`, `REMOVE`, and `REGISTER`.\n\nFor the `REGISTER` operation it provides a parameters object identical to the *Data Object Modified* event handler including the `dataObjInp_t` and `rcComm_t`.\n\nFor the `CREATE` and `REMOVE` operations the `collInp_t` is serialized which provides `logical_path`, `flags`, `opr_type`, and the `cond_input`.\n\n## Administration Event Handlers: Resource, User, Group, and Zone\n\nInteraction with the other nouns in the system is performed solely through the general administration API endpoint which allows for these event handlers to provide identical configuration and behavior.  The events emitted are `CREATE`, `MODIFY` and `REMOVE`.\n\nThe `generalAdminInp_t` is serialized which provides `action`, `target`, and `arg2` through `arg9` which contain various information depending on the action and target in question.  Additionally, depending on the target, `user_name`, `group_name`, `source_resource` or `zone` will be present.\n\n## Policy Engines\n\nThe policy engine framework provides a set of utilities for the creation of a light rule engine plugin which implements a policy that conforms to the Event Handler interface.  It is a goal that the community continues to capture policy which may be reflected as reusable components within this framework.\n\n### Query Processor\n\nThe `irods_policy_query_processor` policy engine wraps the `query_processor` library within the iRODS development environment.  This policy engine will invoke a configured policy for every resulting row from the given query.  Each resulting row is passed to the invoked policy via the parameters as a JSON array `query_results`.  The data within the array arrives in the same order as the columns selected within the query.\n\nExample:\n\n```json\n\"query_string\" : \"SELECT USER_NAME, COLL_NAME, DATA_NAME, RESC_NAME WHERE COLL_NAME = '/tempZone/home/rods' AND DATA_NAME = 'test_put_file'\",\n\"query_limit\" : 1,\n\"query_type\" : \"general\",\n\"number_of_threads\" : 1,\n\"policy_to_invoke\" : \"irods_policy_testing_policy\",\n\"configuration\" : {\n}\n```\n\n### Access Time\n\nThe `access_time` policy engine will annotate a data object with the last access time, which is useful for other policies such as data movement.  By default, a metadata attribute of `irods::access_time` is utilized.  This can be overridden with an `\"attribute\"` string in the `\"configuration\"` of the policy.\n\nExample:\n```json\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-access_time-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-access_time\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n            },\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"put\", \"get\", \"create\", \"read\", \"write\", \"rename\", \"registration\", \"replication\"],\n                            \"policy_to_invoke\"    : \"irods_policy_access_time\",\n                            \"configuration\" : {\n                                \"attribute\" : \"custom_access_time_attribute\"\n                            }\n                        }\n                    ]\n                }\n            }\n```\n\n### Data Replication\n\nThe `data_replication` policy engine will replicate data from a resource to a configured destination resource, or use a mapping from source resource to an array of destination resources.\n\n#### Synchronous Replication\n\nExample:\n```json\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-data_replication-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-data_replication\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n           },\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"put\", \"create\", \"write\", \"registration\"],\n                            \"policy_to_invoke\"    : \"irods_policy_data_replication\",\n                            \"configuration\" : {\n                                \"destination_resource\" : \"AnotherResc\",                                \n                            }\n                        }\n                    ]\n                }\n           },\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"put\", \"create\", \"write\", \"registration\"],\n                            \"policy_to_invoke\"    : \"irods_policy_data_replication\",\n                            \"configuration\" : {\n                                \"source_to_destination_map\" : {\n                                     \"source_resource_0\" : [\"destination_resource_0\", \"destination_resource_1\"],\n                                     \"source_resource_1\" : [\"destination_resource_2\", \"destination_resource_3\"]                                     \n                                }\n                            }\n                        }\n                    ]\n                }\n           }               \n```\n\n#### Asynchronous Replication\n\nExample:\n```json\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-data_replication-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-data_replication\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n           },\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"put\", \"create\", \"write\", \"registration\"],\n                            \"policy_to_invoke\" : \"irods_policy_enqueue_rule\",\n                            \"parameters\" : {\n                                \"delay_conditions\" : \"\u003cPLUSET\u003e1s\u003c/PLUSET\u003e\",\n                                \"policy_to_invoke\" : \"irods_policy_execute_rule\",\n                                \"parameters\" : {\n                                    \"policy_to_invoke\"    : \"irods_policy_data_replication\",\n                                    \"configuration\" : {\n                                        \"source_to_destination_map\" : {\n                                            \"source_resource_0\" : [\"destination_resource_0\", \"destination_resource_1\"],\n                                            \"source_resource_1\" : [\"destination_resource_2\", \"destination_resource_3\"]\n                                        }\n                                    }\n                                }\n                            }\n                        }\n                    ]\n                }\n           }\n```           \n\n### Data Retention\n\nThe `data_retention` policy engine will either remove a given data object or trim a single replica of the data object depending on the `mode`.  The mode may either be `\"trim_single_replica\"` or `\"remove_all_replicas\"`.  The configuration also supports a `\"resource_white_list\"`, an array of resource names that defines which resources may have their data removed.\n\n#### Synchronous Data Retention\n\n```json\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-data_retention-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-data_retention\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n            },\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"replication\"],\n                            \"policy_to_invoke\"    : \"irods_policy_data_retention\",\n                            \"configuration\" : {\n                                \"mode\" : \"trim_single_replica\"\n                            }\n                        }\n                    ]\n                }\n            }\n```\n\n#### Asynchronous Data Retention\n\n```json\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-data_retention-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-data_retention\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n            },\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"replication\"],\n                            \"policy_to_invoke\" : \"irods_policy_enqueue_rule\",\n                            \"parameters\" : {\n                                \"delay_conditions\" : \"\u003cPLUSET\u003e1s\u003c/PLUSET\u003e\",                            \n                                \"policy_to_invoke\" : \"irods_policy_execute_rule\",\n                                \"parameters\" : {\n                                    \"policy_to_invoke\"    : \"irods_policy_data_retention\",\n                                    \"configuration\" : {\n                                        \"mode\" : \"trim_single_replica\",\n                                        \"resource_white_list\" : [\"demoResc\", \"AnotherResc\"]\n                                    }\n                                }\n                            }                            \n                        }\n                    ]\n                }\n            }\n```\n\n### Data Verification\n\nThe `data_verification` policy engine is used to determine if a replica of a data object is correct at rest.  This verification can take one of three methods as configured by administrative metadata annotating the replica's root resource: `irods::verification::type`.  Should another attribute be desired, it may be configured using the `\"attribute\"` setting.\n\nVerification types include: `\"catalog\"`, `\"filesystem\"`, and `\"checksum\"`.\n\nThe `\"catalog\"` mode will stat the object within the catalog to determine that it is properly registered.\n\nThe `\"filesystem\"` configuration will stat the object in the catalog and then stat the object at rest within the storage resource and compare sizes and determine whether they match.\n\nThe `\"checksum\"` configuration will compute a checksum of the replica at rest and compare that with the catalog.  Should no checksum exist in the catalog another good replica will be used to compute the checksum.\n\nExample:\n```json\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-data_verification-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-data_verification\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n            },\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-event_handler-data_object_modified\",\n                \"plugin_specific_configuration\": {\n                    \"policies_to_invoke\" : [\n                        {\n                            \"active_policy_clauses\" : [\"post\"],\n                            \"events\" : [\"replication\"],\n                            \"policy_to_invoke\"    : \"irods_policy_data_verification\",\n                            \"configuration\" : {\n                                \"log_errors\" : \"true\",\n                                \"attribute\"  : \"event_handler_attribute\",\n                            }\n                        }\n                    ]\n                }\n            }\n```\n\n### Checksum Verification\nData integrity may be verified directly with a computation of the replica's checksum, and comparison with the assumed existing catalog value.  This policy requires a `logical_path` and a `source_resource` parameter in order to be invoked correctly.\n\n### Example ConfigurationW\n\nWithin the server configuration:\n\n```json\n\n            {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-verify_checksum-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-verify_checksum\",\n                \"plugin_specific_configuration\": {\n                }\n            },\n\n```\n\nAn implementation of periodic checksum verification:\n\n```json\n{\n    \"policy_to_invoke\" : \"irods_policy_enqueue_rule\",\n    \"parameters\" : {\n        \"delay_conditions\" : \"\u003cPLUSET\u003e1s\u003c/PLUSET\u003e\u003cEF\u003eREPEAT FOR EVER\u003c/EF\u003e\u003cINST_NAME\u003eirods_rule_engine_plugin-cpp_default_policy-instance\u003c/INST_NAME\u003e\",\n        \"policy_to_invoke\" : \"irods_policy_execute_rule\",\n        \"parameters\" : {\n            \"policy_to_invoke\"    : \"irods_policy_query_processor\",\n            \"parameters\" : {\n                \"query_string\"  : \"SELECT USER_NAME, COLL_NAME, DATA_NAME, RESC_NAME WHERE RESC_NAME like 'tier_%'\",\n                \"query_limit\"   : 0,\n                \"query_type\"    : \"general\",\n                \"number_of_threads\" : 1,\n                \"policies_to_invoke\" : [\n                    {\n                        \"policy_to_invoke\" : \"irods_policy_verify_checksum\",\n                        \"configuration\" : {\n                            \"log_errors\" : \"true\"\n                        }\n                    }\n                ]\n            }\n        }\n    }\n}\nINPUT null\nOUTPUT ruleExecOut\n```\n\n### Checksum Verification\nData integrity may be verified directly with a computation of the replica's checksum, and comparison with the assumed existing catalog value.  This policy requires a `logical_path` and a `source_resource` parameter in order to be invoked correctly.\n\n### Example ConfigurationW\n```json\n           {\n                \"instance_name\": \"irods_rule_engine_plugin-policy_engine-filesystem_usage-instance\",\n                \"plugin_name\": \"irods_rule_engine_plugin-policy_engine-filesystem_usage\",\n                \"plugin_specific_configuration\": {\n                    \"log_errors\" : \"true\"\n                }\n           }\n```\n\nAn implementation of a periodic rule to invoke the policy:\n\n```json\n{\n    \"policy_to_invoke\" : \"irods_policy_enqueue_rule\",\n    \"parameters\" : {\n        \"comment\"          : \"Set the PLUSET value to the interval desired to run the rule\",\n        \"delay_conditions\" : \"\u003cPLUSET\u003e10s\u003c/PLUSET\u003e\u003cEF\u003eREPEAT FOR EVER\u003c/EF\u003e\u003cINST_NAME\u003eirods_rule_engine_plugin-cpp_default_policy-instance\u003c/INST_NAME\u003e\",\n        \"policy_to_invoke\" : \"irods_policy_execute_rule\",\n        \"parameters\" : {\n            \"policy_to_invoke\"    : \"irods_policy_filesystem_usage\",\n            \"parameters\" : {\n                \"source_resource\" : \"demoResc\"\n            }\n        }\n    }\n}\nINPUT null\nOUTPUT ruleExecOut\n\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Firods%2Firods_rule_engine_plugins_policy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Firods%2Firods_rule_engine_plugins_policy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Firods%2Firods_rule_engine_plugins_policy/lists"}