With current design, everything should be open (visible permission) by default; user, group, is_public fields removed and permissions assigned by groups
[dean] would be useful to restrict to only authenticated or per group devices/testjobs
So if someone wants to restrict visibility to let’say only authenticated users, it’s a bit tricky to support it with the current design
My plan is to remove every way of having some arbitrary field mess with authorization other then permissions. Does anyone see a problem with removing this field? (physical_owner will still remain in place but it has no say in auth)
[Steve] Check with Dave?
Do they use device owner?
how to allow one group to update one device object? [Rémi]
Is it of any use?
[Rémi] code/design/schema available somewhere?
[Steve] Future plans - when/how/where do we notify of upcoming changes?
lava-devel by default for most things
lava-announce for breaking changes, and give notice
how much notice?
1m? 3m? agree on 2 months for things like BD migrations
2019.05 will have some migrations, then no more yet planned until .08 or .09
When will schema validation become rigid? .08 or .09 as well? [Steve]
Print warnings before then
Schema validation in strict mode will complain about most jobs (80%?), so we can't turn that on!
For now, allow submissions. Also run the validator again in strict mode and print its output as a warning on submission. Can we put the same output into the test log too? Should we?
Some users may look at the LAVA job results page
Some may just grab the logs
Maybe start mailing admins with a daily summary of warnings? Add a management command to check for warnings.
Talk to other people (e.g. Matt about kernelci)
Maybe look into versioning of schemas and support validation of supported versions? Lots of work… :-/
Not complete yet, we still want people running schema checks and letting us know about any problems found