Normalize environment naming: four vocabularies for three environments, and the names mislead

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,922 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
64/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
github-actions, kubernetes, markdown
Ambito
devops, documentation

Direzione di ricerca

Inizia con l'opzione 1, il deliverable che l'autore dice che arriva per primo: aggiungi una singola tabella di mappatura canonica in docs/ che copra vcell_site, i namespace/kustomize overlay di k8s, i percorsi di installazione di webstart/<Site>, serverid e gli URL, oltre all'ordine di cautela stage → dev → prod e l'avviso island/remote serverid=TEST2. Referenziala a croce da .claude/skills/deploy/SKILL.md e dal README di fluxcd, e controlla gli input di dispatch in .github/workflows/ per i valori di vcell_site per confermare che la tabella corrisponda alla realtà. Fatto significa che la tabella esiste, che i tre punti di ingresso vi collegano e che nulla di portante è stato rinominato; nota che nessun maintainer ha commentato da ~54 giorni, quindi conferma la portata prima di toccare superfici oltre docs.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Three environments are referred to by four different vocabularies, and the most common one implies the opposite of what is true. It has already caused one wrong decision (see below) and it costs a lookup every time.

The current mapping

production internal site people use idle sandbox
vcell_site (site_deploy input) rel alpha test
k8s namespace / kustomize overlay prod dev stage
installer directory webstart/Rel webstart/Alpha webstart/Test
serverid (vcell.server.id) REL ALPHA TEST
URL vcell.cam.uchc.edu vcell-dev.cam.uchc.edu vcell-stage.cam.uchc.edu

Plus island and remote, which are overlays with no site name and which both use serverid=TEST2.

Why it is worth fixing

The names invert the risk. dev sounds disposable but is an internal site people actually use; stage sounds like a release-candidate gate but is normally idle and safe to deploy anything to. The real order of caution is stage → dev → prod.

That is not documented anywhere, and it is not derivable from the names, the URLs, or the manifests. It has to be known.

It has already misled someone. While rolling the consolidated service image out one service at a time, the first switch was put on dev on the reasonable-sounding assumption that dev was the safe place to try it. It was moved to stage only because the assumption was corrected in conversation (virtualcell/vcell-fluxcd#29). A reviewer reading dev would have thought it was the cautious choice.

Four vocabularies means four chances to map wrong, and the mapping is not one-to-one in an obvious direction: nothing about alpha suggests dev, and nothing about dev suggests ALPHA.

What changing each would cost

Not all of these are equal, which is why this is a discussion and not a patch:

surface cost
Docs, .claude/skills/deploy/SKILL.md, READMEs trivial
vcell_site workflow input values small — 16 files, but it is a dispatch input people type
Installer directories (webstart/<Site>) breaks existing download URLs; needs redirects
k8s namespace expensive — namespaces cannot be renamed; every resource, PVC and secret must be recreated, with downtime
serverid expensive and risky — it prefixes HPC job names (V_ALPHA_…), appears in stored data and messaging, and changing it may strand in-flight or historical references

So a full rename is almost certainly not the answer.

Options

  1. Document, don't rename. One canonical table in docs/, referenced from the deploy skill and the fluxcd README, stating plainly which environment is which and that the caution order is stage → dev → prod. Zero risk, keeps four vocabularies.
  2. Normalize the cheap layers only. Make the workflow input, docs and skills speak one vocabulary — most likely the site names (rel/alpha/test), since they are already user-visible in installer paths — and keep namespace and serverid as-is with the mapping stated once.
  3. Full rename to purpose-based names (prod / internal / sandbox). Cleanest end state, but requires namespace recreation and a serverid migration; probably only justified if a namespace rebuild is happening anyway.

I would suggest 2, with the mapping table from (1) as the deliverable that lands first, since it removes the actual hazard — someone assuming dev is disposable — without touching anything load-bearing.

Two smaller things to settle alongside:

  • island and remote share serverid=TEST2. They are different clusters so job names should not collide today, but two live environments with the same server id is a latent trap if either ever submits to the same HPC.
  • Neither has a site name at all, so they fall outside every table above.

Not proposing a decision here

Which vocabulary becomes canonical is an architecture call, and the expensive rows above mean the wrong choice is hard to walk back. This issue is to get the mapping written down and the naming decided deliberately.

Lingua principale
Java
Stelle
140
Fork
35
Merge medio
22h 6m
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di virtualcell/vcell

Tutte le issue di virtualcell/vcell

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.