quotas numbers wanted to be set should be bigger than monitored values

[mstfdkmn]

The plugin does not compare and check the quotas that are set with the values monitored. Meaning it lets admins to choose a quotas lower than an already uploaded data.

monitored values:

-bash-4.2$ imeta ls -C /u0137480/home/lt1_d_pilot_003
AVUs defined for collection /u0137480/home/lt1_d_pilot_003:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 13
units:
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 1286416
units:

set quota lower than existing values: -bash-4.2$ irule -r irods_rule_engine_plugin-logical_quotas-instance '{"operation": "logical_quotas_set_maximum_size_in_bytes", "collection": "/u0137480/home/lt1_d_pilot_003", "value": "10"}' null ruleExecOut

list metadata:

-bash-4.2$ imeta ls -C /u0137480/home/lt1_d_pilot_003
AVUs defined for collection /u0137480/home/lt1_d_pilot_003:
attribute: irods::logical_quotas::total_number_of_data_objects
value: 13
units:
----
attribute: irods::logical_quotas::total_size_in_bytes
value: 1286416
units:
----
attribute: irods::logical_quotas::maximum_size_in_bytes
value: 10
units:

[trel]

That is correct/expected at this time.

What would you expect it to do? Not allow the admin to set that value? Delete data?

[mstfdkmn]

I would expect the plugin not to allow the admins to set values lower than monitored - existing data - as metadata.

This is also the case for parent/child collections (hierarchy). Lets say we have a project named as group_A. Inside it, we have personal_usage and common_usage collections. That is, the value chosen for the group_A collection should not be smaller than values set for personal_usage or common_usage .

However if this logic was set to force users to remove data / empty the collection in question, then okay. Though there might be chance to see strange values in our quota related dashboards (not ready yet but we are gonna build in grafana)

[trel]

I would expect the plugin not to allow the admins to set values lower than monitored - existing data - as metadata.

So if the admin cannot set the values whenever/wherever they want... then they will have to set all related/conflicting values first? That seems... possibly very labor intensive? And how would we communicate to the admin what the error was? I'm happy to make it work this way if we can make it helpful / not confusing.

parent/child collections (hierarchy)

This is... going to be tough to get right - and possibly very expensive (when setting the values).

If the 'interior' collections have larger quotas set... then child objects wouldn't be in violation of that quota - but they'd be in violation of the 'outer' quota. That doesn't seem ... 'wrong'... to me. They are independently compared/evaluated/enforced.

Getting all these values set correctly relative to all the other values being set requires a visibility across the entire set of metadata that will be tough / more expensive to monitor and keep correct. I'm not sure this set of code should be doing that monitoring. But of course, willing to be convinced.

Feels like a matter of policy not to have the quotas be confusing / misleading / contradictory.

[mstfdkmn]

Hi Terrell, we discussed this internally and we think the idea of keeping its current way of working is the best. Because;

• The plugin can be used as a kind of mechanism to force users to remove unnecessary data by setting quota lower than existing data size,
• It seems the possibility of setting lower values can be applicable especially for the child collections to keep the project collections clean,
• As you explained above, admins should be flexible to set any values wherever they want and a potential change should not be tough/expensive,

Above all we like this tool and so expect it to work perfectly:)

Thanks.

[trel]

Most excellent.