alrossi
commented
7 years ago (a) that whole embedded bit is left over from an earlier prototype. In the released version, it is not the case that we allow resilience to run as part of the pnfsmanager. So that whole section just needs to be removed.
(b) the 'mirrored' properties: you are right, these should actually be service-only, should not be subject to reconfiguration here. They actually should be eliminated from the properties file. Resilience uses a namespace provider but its interactions with it are read-only, so the defaults are fine.
BTW, pnfsmanager.default-retention-policy actually references dcache.default-retention-policy
if you are running resilience, once I make the change, you should probably redefine the global default rather than pnfsmanager. It will not really matter that much in the end, because, as I said, setting that property is necessary but it has no bearing on resilience's behavior, which is always to retain the access latency and retention policy of the file being copied.
the alteration to the one-of will not be necessary once I remove these properties from the resilience file.
Hi.
I was having a look at the .properties documentation of 2.16, and some things with respect to the resilience service remained pretty unclear to me, even after having again a look at the slides from Umeå.
First, in pnfsmanager.properties, there is this snipped for pnfsmanager.db.connections.max:
What is actually meant here? What is "resilience embedded"? Does it mean the resilience service? And in which sense embedded? Running resilience in some special embedded mode (couldn't find anything about that) or simply having that service within the cluster?
Also the mentioned pnfsmanager.resilience.* do not seem to exist anywhere. And "whatever maximum allowed for normal namespace settings" should probably be clarified as well... e.g. is it just pnfsmanager.db.connections.max or also what NFS doors open to chimera? etc. pp... Also, how does it relate to resilience.db.connections.max ?
Then there are these:
And to me it's really unclear what they do. First, if they mirror the normal settings, why not taking them, i.e.:
resilience.enable.acl = ${pnfsmanager.enable.acl}and so on.Is it strictly necessary to keep them in sync with their pnfsmanager.* counterparts? What happens if one doesn't?
E.g. if resilience.enable.acl = false, does that mean that files copied by resilience won't get ACLs? Similar, does resilience.enable.inherit-file-ownership = false that the don't inherit file ownership (even if for normal operations this would be done due to pnfsmanager.enable.inherit-file-ownership = false)?
And what do resilience.default-access-latency and resilience.default-retention-policy exactly do here? Is it which repol/acclat files copied by the resilience service get? Or files which it considers for duplication?
Our site for example doesn't have tape, so I set:
so would I need to set the resilience.* options to that as well?
Cheers, Chris.
btw: Parts of the options above miss the (one-of?...) and these should probably then also contain their respective pnfsmanager.* counterparts, i.e. not just
(one-of?ONLINE|NEARLINE)resilience.default-access-latency=NEARLINEbut:(one-of?ONLINE|NEARLINE|${pnfsmanager.default-access-latency})resilience.default-access-latency=NEARLINE(of course this would no longer be needed if #3309 was fixed ;-) )