Terrell Russell
Terrell Russell
Yes, these are due to internal searches/matching being done via GenQuery as well.
This could be remedied today with a --json_configuration_file that has already been manipulated to hold the hosts information? steps would be... - start container/vm/cloud instance - copy a templated configuration...
Does it behave better if you were to append the resolved hostname to the 127.0.0.1 line in /etc/hosts?
We could offer a 'skip-local-put-test' option to the setup script... Or not do the check that makes sure that `localhost` routes to self... Not sure what else we can do...
The `irodsTestPutGet` connects to localhost... so I see either we... a) add an option to skip the test entirely, or b) add an option to skip the FQDN resolves to...
Pulling into 4.3.0 so it remains visible.
This is working as designed at the moment. The rule is being fired from within the server (by your rule), so the atomic metadata API is not being hit from...
An alternate approach is to use a 'deeper' PEP, perhaps one of the database PEPs... although we have a different limitation there as we have not completed the transition to...
An msi is fired 'within' the server, already 'inside' the iRODS API boundary - so it does not trigger the API PEPs. If the msi has to be 'redirected' to...