jonasfj, garndt: let me know what your thoughts are. Until now, developers could authenticate with LDAP to schedule any buildbot jobs through BuildAPI. For pulse_actions, we don't have this problem since we give TC permanent credentials with a set of scopes associated to it. The TC python clients allows the user to authenticate through the web for TC which grants temporarily credentials to the script. We could use that model for |mach try|, however, we would need to make sure that temporarily credentials could still schedule tasks that trigger the buildbot-bridge. Nevertheless, that approach would only work for buildbot bridge tasks since normal TC tasks need as many scopes as each task needs. Eventually, more and more jobs would stop being scheduled in Buildbot and the CLI approach would stop working. A general solution would probably be to build a server which requires the user to authenticate through LDAP and we would then go ahead and schedule whatever they were intending to. Since we're moving to the big graph scheduler model, the requests might simply be removing the self-dependcy of the task.
I remembered now the conversation that mdoglio, jonasfj and I had around TaskCluster auth. If there was a way for a developer to schedule directly through the Taskcluster client I would not have to consider building a web app to schedule on their behalf. The biggest problem to schedule directly through the TaskCluster client is that they don't have all the right scopes to trigger tasks directly themselves. Instead, we decided to use automation to schedule on behalf of the users to limit the scopes given to them. Now, determining if the API should be on relengapi, taskcluster, a new Heroku web app or treeherder is left to be determined.
In bug 1194264 we fixed this. With the deployment of roles, users can now use TC to schedule jobs by creating a role which assumes:client-id:bbb-scheduler
I don't think we should have any other role assuming a client-id role. Rather, users should create a client with the same scopes that you gave to your client.
I thought the idea is for roles to be able to assume multiple roles. Or is a role starting with "client-id" role different?
In principle, that's possible, yes, but that doesn't mean it's a good idea. It would mean that the other client-id is impersonating the client-id 'bbb-bridge', rather than getting the scopes that it needs to do its thing. We could potentially make a tree of "utility" roles to make configuration of new clients easier. In this case, that might be role util:bbb-scheduling scheduler:create-task-graph queue:define-task:buildbot-bridge/buildbot-bridge then jane dev could create a new clientId "janes-bbb-client", and set up role client-id:janes-bbb-client assume:util:bbb-scheduling For utils with more than two scopes, this could save a lot of typing. But the downside is that once we have a way to tie scopes to individual people (we don't right now, we just haven't put any locks no the doors, which is why BBB and Balrog and signing are turned off right now), we would need to grant everyone who deserved it access to the appropriate util roles, studiously avoiding giving them roles they shouldn't have (e.g., assume:util:release-signing). Very soon, we'll be deploying a system that will let you create credentials for this sort of thing. In this case, you'd need to write a command-line client that knows what scopes it wants (the two above). It would start a local webserver (so you'd have to runt he client on your laptop) and print a URL to the terminal. You click that URL, sign in via Okta, Mozillians, Github, etc., and click "authorize". Then the client continues with temporary credentials containing those scopes. Unfortunately, they only last for three days so you need to do this fairly frequently. So for now, let's stick to making the instructions for this process as follows: * create a new client * give that client scopes `scheduler:create-task-graph` and `queue:define-task:buildbot-bridge/buildbot-bridge` by editing the role named `client-id:$clientId` where $clientId is the name of the client you just created. We're working on making this kind of thing simpler -- in fact, you've given us a good user story to work with as we define this sort of thing.
dustin, thank you for taking the time to explain it so well. That second new system is something I'm happy to test out. Please let me know when I can get involved with it.