Details
-
Bug
-
Status: Closed
-
Minor - P4
-
Resolution: Won't Fix
-
None
-
None
Description
I'm opening a new ticket, since we have a few in this vein that are scattered around, but the underlying issue is general, as well as being easy to fix.
A brief summary of the issue:
(Before state)
- Evergreen provides ids for various records that are immutable – explicit API
- Evergreen requires users to create a project with some id; this enforces that users specify something that makes sense to them – explicit API
- Evergreen formats child record ids based on the parent record ids – observed API (Hyram's Law)
- The id/reference/link for a given record is predictable – observed API
- The id/reference/link for a given record is user-friendly – observed API
- It is easy to interrogate and consume Evergreen data, even outside the context of Evergreen – observed API
So, people will call something "sys-perf-v5.0" or "mongodb-mongo-v5.0", and there is a fan out of workflows and tooling that integrate with the above APIs. Now, people will of course want to rename it to "system-performance-5.0" or "mongodb/mongo-5.0". So clearly they would like some kind of mutable identifier.
There are a couple ways to allow for the mutable identifier:
- similar to display_name, attach it as metadata to the project record for reporting purposes
- Insert above points/features of Evergreen, they all hold true still
- Updating workflows/tooling/integrations/models is opt-in, since the change is entirely backwards compatible
- Supporting links/routes based on project_identifier is still possible
- refactor our domain model, to use the mutable identifier as the main reference for a resource (the currently implemented strategy/requirements).
- Evergreen provides ids for various records that are immutable – explicit API
- Evergreen provides mutable identifiers – explicit API
- Evergreen doesn't require users to create a project with some id;
this enforces that users specify something that makes sense to them UUID used by default.– explicit API Evergreen formats child record ids based on the parent record ids mutable identifiers– observed APIThe id/reference/link for a given record is predictable – observed APIThe id/reference/link for a given record is user-friendly – observed APIIt is easy to interrogate and consume Evergreen data, even outside the context of Evergreen – observed APIUpdating workflows/tooling/integrations/models is opt-in, since the change is entirely backwards compatible- Supporting links/routes based on project_identifier is still possible
The strikethroughs above have led to broken integrations and hacks across tooling (see linked tickets). We need to remediate that now.
AC/Requirements:
- Ensure all immutable ids are human-friendly.
- Generate mutable ids from one another based on the previous parent-child schema. Do not attempt to generate references based on mutable data.
In terms of implementation, you can likely copy the display_name code, and add some routing support for that as a non-breaking change.
Attachments
Issue Links
- causes
-
EVG-15240 Fix broken links to evergreen task page on sys-perf-5.0 and performance-5.0 projects
-
- Debugging
-
-
EVG-15129 task_stats endpoint not returning data for 5.0 evergreen projects
-
- Closed
-
-
EVG-15222 Require specification of user-friendly immutable project IDs
-
- Debugging
-
- duplicates
-
EVG-15222 Require specification of user-friendly immutable project IDs
-
- Debugging
-
- is depended on by
-
DAG-2133 Remove the project id map hack implemented in TIG-3293
-
- Needs Scheduling
-
- related to
-
EVG-16128 Make it hard for users copying existing performance projects that have an immutable id to use mutable id
-
- Closed
-