Rename the 12 unprefixed config env vars to VCELL_* (needs vcell-fluxcd coordination)

Open
  • Is something wrong?
#1,921 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
62/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Quiet
Tech stack
docker, java
Domain
devops

Research direction

Start with tier 1: keystore and workingDir are Dockerfile-only, so drop their -D flags and delete their lines from vcell-core/src/main/resources/vcell-legacy-env-names.properties. The other 10 require vcell-fluxcd changes first (add VCELL_* alongside the legacy name, then remove -D, then remove the legacy name) because a rename with the -D flag still present silently resolves empty. Run LegacyEnvironmentNamesTest, which re-derives the table from the Dockerfiles and fails on drift; done when all 12 lines are gone, the test passes, and prod is verified.

Written by the indexing model from the issue text.

Description

Follow-up to #1920, which is additive and deliberately does not do this.

Why

#1920 lets a service read configuration from its environment instead of from a wall of -D flags. Because the deployment supplies configuration under short legacy names, those 81 names sit in vcell-legacy-env-names.properties as a fallback. 12 of them are short and unprefixed:

legacy property target
dburl vcell.server.dbConnectURL VCELL_SERVER_DBCONNECTURL
dbuser vcell.server.dbUserid VCELL_SERVER_DBUSERID
dbdriver vcell.server.dbDriverName VCELL_SERVER_DBDRIVERNAME
serverid vcell.server.id VCELL_SERVER_ID
jmsuser vcell.jms.user VCELL_JMS_USER
batchuser vcell.htc.user VCELL_HTC_USER
batchhost vcell.htc.hosts VCELL_HTC_HOSTS
htcnodelist vcell.htc.nodelist VCELL_HTC_NODELIST
dbpswdfile vcell.db.pswdfile VCELL_DB_PSWDFILE
jmspswdfile vcell.jms.pswdfile VCELL_JMS_PSWDFILE
keystore vcellapi.keystore.file VCELLAPI_KEYSTORE_FILE
workingDir cli.workingDir CLI_WORKINGDIR

A name this generic can collide with something unrelated in the environment. #1920 narrowed the blast radius by making the provider per-service rather than a PropertyLoader default — the desktop client and CLI no longer read the environment at all — but inside the containers the surface remains, and renaming removes it rather than documenting it.

⚠️ Ordering is mandatory, and getting it wrong fails silently

Do not rename an environment variable while its -D flag still exists. The flag expands the old name, so after a rename it expands to empty — and an empty system property is not absent. It wins over the environment, and validateSystemProperties counts it as set.

Demonstrated against the real provider:

A) env renamed, -D flag removed        ->  resolved = [jdbc:good]   (length 9)
B) env renamed, -D flag still present  ->  resolved = []            (length 0)

In case B the service starts with an empty DB URL and no error. Per variable, the -D flag must go first (or both names must be set during the transition).

We cannot guard this by treating blank as unset: htcnodelist= is legitimately empty in all five overlays.

Safe sequence, per variable

#1920 resolves in this order — system property, then vcell.server.id / vcell_server_id / VCELL_SERVER_ID, then the legacy name — so the modern name wins and each variable can move on its own:

  1. vcell-fluxcd: add VCELL_* alongside the legacy name, both set. Behaviourally inert — the -D flag still wins.
  2. vcell: delete the -D flag from the Dockerfile. The provider now resolves the modern name; the legacy name remains as a backstop.
  3. Deploy, verify.
  4. vcell-fluxcd: remove the legacy name.
  5. vcell: remove the line from vcell-legacy-env-names.properties.

Every step is independently reversible, and no step has a window where the value is unreachable.

Precedent already in the tree: kustomize/config/dev/shared.env carries both softwareVersion and VCELL_SOFTWAREVERSION.

Who sets what

Measured against vcell-fluxcd@origin/main (a6feb47) and this repo:

name Dockerfile ENV/-D docker-compose fluxcd config/*.env fluxcd base/*.yaml env:
dburl dbuser dbdriver ✅ 7 5 —
serverid jmsuser ✅ 8 5 —
batchuser batchhost htcnodelist ✅ 2 10 —
dbpswdfile jmspswdfile ✅ — — 5
keystore workingDir ✅ — — —

Three tiers by coordination cost:

  1. keystore, workingDir — Dockerfile-only. No vcell-fluxcd change at all; can be done unilaterally, and are the natural first move.
  2. The 8 .env keys — live in kustomize/config/<overlay>/{shared,sched,submit}.env across dev, island, prod, remote, stage. Base manifests consume them via envFrom: configMapRef (whole ConfigMap injected), so a key rename needs no base-yaml edit.
  3. dbpswdfile, jmspswdfile — literal env: entries in kustomize/base/*.yaml (5 files each), so these two do need base-manifest edits.

docker/swarm/docker-compose*.yml also sets several of these. Per [No Swarm, Only K8s], that tree is not a live deployment path, but it should be updated for consistency or explicitly declared stale.

Out of scope

docker/build/batch/Java{SimExe,Preprocessor,Postprocessor}64 build their own -D list on the HPC node and are a separate surface — 6 properties appear only there, and 7 use different env names. In particular vcell.jms.sim.{host,port,restport}.external deliberately point at the internal names because the solver runs inside the cluster; these are intentional and must not be "reconciled".

Done when

  • The 12 are VCELL_* in vcell-fluxcd and in the Dockerfile ENV/-D references
  • Their lines are gone from vcell-core/src/main/resources/vcell-legacy-env-names.properties
  • LegacyEnvironmentNamesTest passes (it re-derives the table from the Dockerfiles and fails on drift)
  • prod deployed and healthy on the renamed variables

Ideally the remaining 69 aliases follow the same path, after which the table and its test can be deleted outright.

Dominant language
Java
Stars
140
Forks
35
Avg merge
11h 28m
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from virtualcell/vcell

All issues in virtualcell/vcell

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.