[tracker] taskcluster clients must be able to interact with different clusters

ASSIGNED
Assigned to

Status

ASSIGNED
a year ago
2 months ago

People

(Reporter: bstack, Assigned: pmoore)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Details

(Reporter)

Description

a year ago
At the moment, we expect this will work by setting some sort of environment variable or passing in a configuration option. This would probably be called TASKCLUSTER_BASE_URL or something along those lines and would contain a string that is the "root" of a cluster. At this root we will be running a reverse-proxy that sends requests to services based on the path. Examples:


> export TASKCLUSTER_BASE_URL="taskcluster.imbstack.com"

> const taskcluster = require('taskcluster-client');
> const auth = new taskcluster.Auth({});
> await auth.ping(); // would make a request to taskcluster.imbstack.com/auth/v1/ping

In addition to this, the client should be able to interact with the cluster even if it has new endpoints added or current endpoints have api changes. We have yet to 100% settle on a solution to this, but for language clients like Python/JS/etc it could involve being able to tell the client that all sub-clients created should be dynamically generated at runtime. Example:

> export TASKCLUSTER_BASE_URL="taskcluster.imbstack.com"

> const taskcluster = require('taskcluster-client');
> taskcluster.config({generateDynamicClients: true});
> const auth = new taskcluster.Auth({});
> await auth.newCrazyThing(); // would make a request to taskcluster.imbstack.com/auth/v1/newCrazyThing

The above example is not set in stone, just a guiding principle to follow. The clients that are for static languages would be rebuilt during the cluster build process. The dynamic language clients can/will also be rebuilt during that process but we allow them to be runtime-configurable to avoid needing to publish new clients for every development change and to avoid issues with circular dependencies during cluster bootstrapping.

Please add more of your thoughts here! I expect what I've written is incomplete/wrong!
(Reporter)

Updated

a year ago
Depends on: 1428420
(Reporter)

Updated

a year ago
Depends on: 1428421
(Reporter)

Updated

a year ago
Depends on: 1428422
(Reporter)

Updated

a year ago
Depends on: 1428426
(Reporter)

Updated

a year ago
Assignee: nobody → bstack
Status: NEW → ASSIGNED
(Reporter)

Comment 2

a year ago
The first half of this work is now done. The work to allow easy dynamic client building will come later.
(Reporter)

Updated

11 months ago
Blocks: 1455629
(Reporter)

Comment 3

11 months ago
We're starting to lose faith in our current plan for this work. We have scheduled a meeting on Monday to discuss the path forward.
(Reporter)

Updated

11 months ago
Blocks: 1457608
(Reporter)

Comment 4

11 months ago
We've decided this actually works after all. Updates:


The env var is now `TASKCLUSTER_ROOT_URL`. We are going to use a library called taskcluster-lib-urls to generate paths based on that.
(Reporter)

Updated

11 months ago
Depends on: 1460012
(Reporter)

Updated

10 months ago
Summary: taskcluster clients must be able to interact with different clusters → [tracker] taskcluster clients must be able to interact with different clusters
Pete is currently working on this..
Assignee: bstack → pmoore
(Assignee)

Comment 6

5 months ago
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #5)
> Pete is currently working on this..

RFC 128 has now been approved, and covers the design in detail:

https://github.com/taskcluster/taskcluster-rfcs/blob/rfc0128/rfcs/0128-redeployable-clients.md
Component: Redeployability → Services
Product: Taskcluster → Taskcluster
You need to log in before you can comment on or make changes to this bug.