Uploaded image for project: 'Evergreen'
  1. Evergreen
  2. EVG-16179

Restore Immutable ID scheme and routes

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor - P4
    • Resolution: Won't Fix
    • None
    • product
    • 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 API
        • 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
        • 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

      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

          Activity

            People

              cristopher.stauffer@mongodb.com Cristopher Stauffer
              alexander.costas@mongodb.com Alexander Costas (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: