describing who can see restricted lava jobs

Michael Hudson-Doyle michael.hudson at linaro.org
Wed Feb 22 01:21:57 UTC 2012


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



More information about the linaro-dev mailing list