| 25 Aug 2021 |
andi- | It would still be only one person but that would already add another dimension of offloading. | 14:10:48 |
andi- | I can see that this might be an issue as for example the scheduling shares are managed within a jobset and not from the "outside". | 14:12:03 |
sterni | I agree that that is not ideal, but tbh even with a jobset's internal configuration you'd be able to exact some kind of abuse, so owners would need to be trustworthy regardless | 14:13:35 |
andi- | Yeah. I am more thinking in line of "I need to be able to restart / cancel / ... a job" within a specific jobset without having to hand out global permissions like we do right now.l | 14:14:13 |
andi- | It isn't an issue but I think it would bel nice to be able to provide more access to hydra to trusted contributors with the ability to keep the scope smaller. | 14:14:51 |
sterni | probably we'd need to implement an ACL system at some point which allows to give out permissions per jobset | 14:15:51 |
sterni | maybe even per job, so maintainers can restart “their” jobs if they are flaky | 14:16:06 |
sterni | * maybe even per job, so maintainers can restart “their” jobs if they are flaky, but that may be unnecessary overkill | 14:16:17 |
andi- | I tend to agree even if flaky jobs should be fixed and restarting is just a temporary measure. | 14:16:51 |
tomberek | anyone familiar with githubpulls usage? I've been trying to get it working. I have a generative project spec that produces what seems to be correct output (and it works when i use it directly as a spec.json). But jobs are not created. | 14:20:26 |
@grahamc:nixos.org | andi-: I think it is just on the project-level | 14:21:13 |
@grahamc:nixos.org | finer grained ACLs would be cool, I wonder to what extent user-based is sufficient | 14:21:30 |
sterni | GitHub teams hydra plugin -.- | 14:24:21 |
sterni | * GitHub org teams hydra plugin -.- | 14:24:25 |
@grahamc:nixos.org | sounds like a cool idea | 14:25:06 |
sterni | does it already have a group concept? | 14:25:24 |
@grahamc:nixos.org | no | 14:25:29 |
@grahamc:nixos.org | :) | 14:25:36 |
andi- | Pluggable permissions might be a first step. | 14:26:37 |
andi- | e.g. for all of the 3-4 role functions that we have now allow them to be extended by plugins. | 14:26:54 |
@grahamc:nixos.org | yeah | 14:27:08 |
@grahamc:nixos.org | sounds like a cool idea | 14:27:12 |
andi- | Then the first step could be to give each committer restart permissions. | 14:27:32 |
@grahamc:nixos.org | 😬 maybe :) | 14:28:08 |
andi- | In reply to @grahamc:nixos.org 😬 maybe :) If not restart what else? Nothing? :D | 14:28:22 |
andi- | I think that is the lowest priv we have except maybe the bump-to-front role | 14:28:35 |
sterni | bump-to-front is riskier arguably since it messes with normal scheduling | 14:29:01 |
@grahamc:nixos.org | we actually have ✨policy ✨ about this | 14:29:34 |
andi- | I think aborting many jobs is costlier than slightly changed scheduling. It isn't a clear line. | 14:29:48 |
@grahamc:nixos.org | https://github.com/NixOS/nixos-org-configurations/wiki/Hydra-Accounts#deciding-on-roles | 14:29:49 |