Hi all,
The LAVA team is working on support for private jobs -- we already have some support for private results, but if the log of the job that produced the results is publicly visible, this isn't much privacy.
The model for result security is that a set of results can be:
- anonymous (anyone can see, anyone can write) - public (anyone can see, only owning user or group can write) - private (only owning user or group can see or write)
Each non-anonymous set of results is owned by a group or user. I think this model is sufficiently flexible -- the only gap I can see is that it's not possible to have a stream where a subset of the people who can see it can submit results to it.
Clearly it makes sense to have the set of people who can see the eventual results and see the job output be the same. Currently the former group is encoded in the stream name of the submit_results action, for example:
{ "command": "submit_results", "parameters": { "server": "http://locallava/RPC2/", "stream": "/private/personal/mwhudson/test/" } }
would place results in a stream called 'test' that only I can or
"stream": "/public/team/linaro/kernel/"
identifies a stream that anyone can see but only members of the linaro group can put results in.
The scheduler *could* read out this parameter from the job json and enforce the privacy rules based on this, but that seems a bit fragile somehow. I think top level attribute in the json describing who can see the job would make sense -- we can then make sure the stream name on the submit_results matches this.
Does the /{public,private}/{personal,team}/{team-or-user-name} syntax make sense to people? I think it's reasonably clear and nicely terse.
We should do as much validation at submit time as we can (rejecting jobs that submit to streams that do not exist, for example).
Cheers, mwh