Retire the drs.microbiomedata.org subdomain (update Mongo data accordingly)

[eecavanna]

Background

"DRS" stands for "Data Repository Service".

There is a DNS record (of type CNAME) for drs.microbiomedata.org defined on LBLnet (via IP Request). Since August 20, it has pointed to Cloudflare (previously, it pointed to Spin). There is a CNAME on Cloudflare that points to Spin. On Spin, there is a path on the production api ingress that "listens" for drs.microbiomedata.org and routes it to the production Runtime.

In practice, when I visit https://drs.microbiomedata.org, I am redirected to the Runtime (Swagger UI).

There is some documentation related to this subdomain, in the project README; here: https://github.com/microbiomedata/nmdc-runtime/?tab=readme-ov-file#data-exports

Conversations

A team member familiar with the subdomain wrote the following on Slack, in response to me asking whether there would be any harm in us deleting the aforementioned DNS records and ingress configuration:

There are links within “objects” collection documents that use that hostname IIRC, but if we change drs.microbiome to api.microbiome across database document values and across the documentation/codebase, I’d be okay with losing it.

I confirmed there is, indeed, at least one document in the database that has a field containing a URL that begins with drs://drs.microbiomedata.org (note the drs instead of https 🤷 ). In this example, the name of the field is self_uri and the document's id value is 6m4e-1vbv-03. You can find the document by issuing this query on the production nmdc database:

db.getCollection("objects").find({ "id": "6m4e-1vbv-03" });

Tasks

• 1. Update Mongo documents to use api.microbiomedata.org instead of drs.microbiomedata.org
  • ⚠️ See Concern 1 below
• 2. Remove references to drs.microbiomedata.org from the codebase
• 3. Remove references to drs.microbiomedata.org from documentation

Concerns

1. The "protocol" in the example occurrence above was drs and not https. I don't know what types of clients use that drs protocol. Would the correct "drop-in replacement" for drs://drs.microbiomedata.org be (a) drs://api.microbiomedata.org or (b) https://api.microbiomedata.org?

[eecavanna]

1. The "protocol" in the example occurrence above was drs and not https. I don't know what types of clients use that drs protocol. Would the correct "drop-in replacement" for drs://drs.microbiomedata.org be (a) drs://api.microbiomedata.org or (b) https://api.microbiomedata.org?

Hi @dwinston, during Thursday's infrastructure meeting, @shreddd and I talked about moving forward with getting rid of the drs.microbiomedata.org subdomain. I am curious what you think about this "concern" I mentioned.

[eecavanna]

1. Update Mongo documents to use...

Assuming there is nothing in the schema that says the current URL is valid (with respect to the schema) while the proposed URL is invalid (with respect to the schema), this update can be done live (e.g. via a changesheet or some other Runtime API endpoint) instead of via a migration.