Scoping rules for data stores?

[mogul]

@jeccles-eop ran into a thing where a process under our site-administration folder could not access a data store that's in another process group. We're assuming that the process group hierarchy is acting as an access boundary for data stores... Is that right, and if so are there any exceptions to that rule? (Also it'd be good to have documentation on this.)

[mogul]

I'm guessing that site-administration processes that run during an init-process could use the API to manipulate data stores, but is there any other way?

[burnettk]

Yes, they can be scoped to process groups. Wrote some things at sartography#2652. I believe it would be possible to define the data store at the root level to allow all process groups access.

[mogul]

Thanks for the write up. Can you expand it to cover called processes?

For example, if we call a process that is lower in the hierarchy than a data store that the called process needs to access, but both the called process and the data store are in a neighboring branch of the PG hierarchy from the caller, will the called process be able to access the data store?

[burnettk]

It is currently based on the caller's location: https://github.com/sartography/spiff-arena/pull/2658/files#diff-0a656300f7f57c78922bea34325c0fb8a3f3d1cc79a1d83deb4777194de5b940

[mogul]

How happy are you with that "currently"? Right now that gives us the problem I described, and also removes the ability to make fully abstracted processes usable by lots of process groups, unless they rely on "global" data stores.