Explore potential name changes of NERC to MOC

[msdisme]

This story is to explore what would be involved in changing the name of the NERC to the MOC. The reason is that the state, the NSF, and many of our customers think of us as the MOC, not th NERC.

The goal is identify places where NERC would need to change MOC , as well as areas where we could get away with having MOC and NERC DNS items point at same things - eg. would that work for https://console.apps.shift.nerc.mghpcc.org/?

Here is an AI assisted (sorry Naved) list of what msd could think of, please expand on it or edit it as you see fit. The AI was kind enough to suggest a seperate semantic layer with a bunch of coldfront and biling stuff in it - I included it but suspect @knikolla @QuanMPhm and @naved001 will have a lot to change. Next step is getting dev and marketing eyes on this list, deciding if we want to proceed, and if so generating epics/stories if we decide to proceed.

NERC → MOC Rename Backlog

---

Platform Identity / User-Facing Services

• Update service name in user-facing platform identity

  Story Details

  As a researcher
  I want the platform name reflected consistently in login banners and dashboards
  So that I know I am accessing the correct cloud service

  Acceptance Criteria:

  • Horizon UI headers updated
  • OpenShift UI headers updated
  • RHOAI UI headers updated
  • SSH MOTD updated
  • OPE (Jupyter) landing page updated
  • TLS certificates CN/SAN reviewed if service FQDNs include nerc

---

Identity and Access Management

• Update IAM-related naming

  Story Details

  As an operator
  I want identity and access management components to reference the updated platform name
  So that partner integrations and user provisioning reflect the correct service identity

  Acceptance Criteria:

  • Keystone realm descriptions updated
  • LDAP display names updated
  • OIDC provider names updated
  • SCIM provisioning labels updated (if used by partners)

---

ColdFront – UI / Messaging Rename (Presentation Layer)

• Rename resource provider and service catalog entries

  Story Details

  As a PI
  I want allocation requests to reference the updated platform name
  So that proposal language matches what was awarded

  Acceptance Criteria:

  • Provider display name updated in allocation types
  • Request workflows updated
  • Approval emails updated
  • Billing UI updated
  • Historical allocations retain original label (“NERC – legacy”)

• Update billing exports and invoice descriptors

  Story Details

  As a finance administrator
  I want billing exports to reflect the updated platform name
  So that invoices align with institutional documentation

  Acceptance Criteria:

  • CSV headers updated
  • Invoice memo fields updated
  • Monthly PI usage reports updated
  • Cost dashboards updated
  • Historical billing events unchanged

• Update quota and denial messaging

  Story Details

  As a user
  I want allocation and quota messages to reflect the updated platform name
  So that denial or usage messaging is not confusing

  Acceptance Criteria:

  • API responses updated
  • ColdFront UI updated
  • Denial emails updated

---

ColdFront – Semantic Layer (Service Introduction)

• Introduce new MOC service identifier in ColdFront

  Story Details

  As an operator
  I want to introduce a new service identifier for MOC
  So that new allocations reference the updated platform name while preserving historical NERC allocation continuity

  Acceptance Criteria:

  • New service code created for MOC platform
  • Existing NERC service identifier retained
  • Allocation types mapped to new MOC service code
  • Allocation workflows updated to reference MOC for new requests
  • Historical allocations remain associated with NERC service

• Duplicate and re-associate rate tables for MOC service

  Story Details

  As an operator
  I want MOC allocations to use distinct rate tables
  So that billing continuity for legacy NERC allocations is preserved

  Acceptance Criteria:

  • Existing NERC rate tables duplicated
  • New MOC rate tables associated with MOC service code
  • Legacy NERC allocations retain original rate table associations
  • Rate versioning verified across service boundary

• Update project resource mappings for new MOC allocations

  Story Details

  As an operator
  I want new project resource mappings to reference MOC
  So that new allocations resolve against the correct service

  Acceptance Criteria:

  • Project resource mappings duplicated for MOC service
  • New allocation workflows reference MOC mappings
  • Existing NERC allocations retain original mappings

• Maintain renewal continuity for legacy NERC allocations

  Story Details

  As a PI
  I want allocation renewals to preserve original service association
  So that historical usage and reporting continuity are not disrupted

  Acceptance Criteria:

  • Renewal workflows preserve original service label
  • Renewal allocations remain associated with NERC service
  • Renewal notifications updated to reflect platform rename

• Enable dual-service reporting support during transition

  Story Details

  As an operator
  I want reporting tools to recognize both NERC and MOC services
  So that usage and billing can be aggregated across rename boundary

  Acceptance Criteria:

  • Billing exports distinguish between NERC and MOC allocations
  • Usage dashboards aggregate across both services
  • API consumers validated for dual-service reporting
  • Legacy allocation reporting unchanged

• Validate downstream consumers of ColdFront service identifiers

  Story Details

  As an operator
  I want downstream systems to resolve both service identifiers
  So that rename does not disrupt reporting or provisioning workflows

  Acceptance Criteria:

  • Export pipelines validated
  • Cost reporting tools validated
  • Provisioning integrations validated
  • Allocation audit logs reviewed

---

Documentation / Onboarding / Training

• Replace platform references in user documentation

  Story Details

  Acceptance Criteria:

  • nerc-docs GitHub updated
  • MGHPCC onboarding materials updated
  • Jupyter onboarding PDFs updated
  • Research workflow examples updated
  • Grant language templates manually reviewed
  • PI welcome packets updated

• Update onboarding automation

  Story Details

  Acceptance Criteria:

  • Ticketing auto-responses updated
  • NetBox integration labels updated
  • User group creation templates updated

• Update training and course materials

  Story Details

  Acceptance Criteria:

  • Syllabi updated
  • Workshop slide decks updated
  • Recorded video captions updated

---

Infrastructure / Networking / Inventory

• Review and update DNS references

  Story Details

  Acceptance Criteria:

  • *.nerc.* subdomains inventoried
  • Migration / alias / retention decision made
  • External researcher workflows validated

• Update NetBox site and tenant names

  Story Details

  Acceptance Criteria:

  • Site labels updated
  • Tenant descriptions updated
  • Prefix descriptions updated

---

Observability / Telemetry

• Update observability metrics namespace

  Story Details

  Acceptance Criteria:

  • Prometheus labels updated
  • Grafana dashboards updated
  • Loki log streams updated
  • Usage metering pipelines updated
  • New workloads labeled moc
  • Legacy workloads queryable as nerc

---

Governance / External Artifacts

• Update MOU templates

  Story Details

  Acceptance Criteria:

  • Institutional partner agreements updated
  • GPU leasing agreements updated
  • Storage participation documentation updated

• Update governance artifacts

  Story Details

  Acceptance Criteria:

  • Steering committee charters updated
  • OSAC collaboration language updated
  • Red Hat Research partner descriptions updated
  • MassTech reporting artifacts updated

• Update public-facing content

  Story Details

  Acceptance Criteria:

  • MGHPCC website updated
  • BU Hariri site updated
  • MassOpen.Cloud updated
  • NAIRR Pilot listings updated

---

Operations / DevOps

• Update operational runbooks

  Story Details

  Acceptance Criteria:

  • references in runbooks updated
  • Incident templates updated

• Update CI/CD pipelines and repository references

  Story Details

  Acceptance Criteria:

  • GitHub org descriptions updated
  • Repo READMEs updated
  • Repo names updated

---

Communication / Change Management

• Draft PI notification

  Story Details

  Acceptance Criteria:

  • Communication drafted
  • Allocation continuity explained
  • Billing continuity explained
  • Scope expansion rationale provided

• Implement dual-brand transition period

  Story Details

  Acceptance Criteria:

  • “MOC Cloud (formerly NERC)” banner implemented across login portals
  • Invoice descriptors updated during transition
  • Onboarding emails updated

[msdisme]

Orran perspective: not time sensitive - tooling name is secondary. Public facing websites and marketing do it sooner. NERC as a cluster of the MOC. Greg and Chris prioritization - perspective?

[naved001]

Re: changing openshift cluster names.

From this redhat article: https://access.redhat.com/solutions/4853401

It is not possible to change the domain for the API, internal or external. It is now possible to change the domain of the OpenShift web console (in OCP 4.8+) and the OAuth server (in OCP 4.9+).

Looks like the web console name may be changed, but not the domain name for API.

[QuanMPhm]

For Coldfront, the only user-visible "NERC" string is for the Openshift resources (NERC, NERC-OCP and NERC-OCP-EDU), these can be easily manually renamed to MOC... or however we see fit