1459437 - Standardize options to libraries as much as possible

Status: RESOLVED FIXED

(Taskcluster :: Services, enhancement)

Description

[Brian Stack [:bstack]]

I believe we can simplify main.js in most services in addition to allowing us to:

1. Set rootUrl easily across all services
2. Avoid subtle bugs and needing to check docs for every single option
3. Make `version` (version 0 in references and "v1" in most urls) a single sensible value that we can actually change if desired.
4. Easily use taskcluster-lib-urls without needing to munge config every time


I propose the following (this is after a bit of hacking on some libraries to see if it makes sense):


{
  rootUrl: '...' // The rootUrl of the entire cluster
  name:  '...' // The name of this service (e.g. auth, queue, github)
  version: '...' // The version of the service as a string (e.g. v0, v1, v200)  
}

The biggest change I would like us to do if we do this is to make the `version` in schemas a string that begins with "v" and is followed by numbers rather than only the integer 0.

Thoughts? Nothing I say here is set in stone! We can take this to an rfc if we really want to, but we will need to do this soon to move forward with redeployability and it doesn't really change the external interface of TC at all, so I figure no need to spend a ton of time on it.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

Where would this proposed object appear?

Comment 2

[Brian Stack [:bstack]]

Oh sorry for the lack of clarity. This isn’t an object, just 3 options that are always passed to a library that involves any of those fields.

For instance, right now we have a lot of places in various main.js where we hardcode prefixes and paths that involve those three fields. I think if all libraries take these three fields instead, they can construct whatever they need. This would replace baseURl, schemaPrefix, authRootUrl, monitor.project, validator.prefix, exchangePrefix, etc.

Sorry for the terseness, writing from phone.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

I think this makes sense.  It doesn't quite cover exchangePrefix, but I think tc-pulse is the answer to that problem.

Comment 4

[Brian Stack [:bstack]]

The conversation below more accurately shows what I am describing here:

<dustin> like these three parameters we pass to "libraries" -- which libraries
<bstack> well, tc-lib-api, lib-monitor, lib-testing, lib-validate are the ones so far
<bstack> and then in config.yml we could have these three fields defined in the same place
<bstack> and then it kinda works the same in every main.yml
<dustin> what 'name' does lib-monitor need?
<dustin> oh
<bstack> what we call "project" right now
<bstack> could be constructed from name probably/
<dustin> I see, this is an object describing *this* service
<bstack> maybe not 100% of the time
<bstack> yeah
<dustin> "I'm auth v3 running at https://foo.com"
<bstack> because we describe "this" service again and again in different ways in main.js
<bstack> yep
<dustin> yeah
<dustin> ok, makes sense

Comment 5

[Brian Stack [:bstack]]

After some discussion, we've added a fourth field and changed the name of one of them:



{
  rootUrl: '...', // The rootUrl of the entire cluster
  serviceName:  '...', // The name of this service (e.g. auth, queue, github)
  projectName: '...', // The name of the repository (with taskcluster- prefix when applicable)
  version: '...', // The version of the service as a string (e.g. v0, v1, v200)  
}

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

In terms of definitions:

projectName: name of github repo (including taskcluster- prefix)
  ec2-manager
  taskcluster-auth
  azure-entities
  taskcluster-lib-validate

serviceName: only for services, drops taskcluster- prefix if any
  ec2-manager
  auth

We already use both - this is just giving them names.

Comment 7

[Brian Stack [:bstack]]

Now we just need to update these in services! The work in libraries here is done.