Commit 42c5820b authored by Vacaliuc, Bogdan's avatar Vacaliuc, Bogdan
Browse files

adjust a few items (blxx pattern, uid/gid and -e switch) 

- NB: ref-l-vtwinN is not a valid name, but bl4b-vtwinN is
- slowcontrols_developers GID is 43647 on beamlines
- controls UID is 88888 on beamlines
- git-release.sh has -e switch, but this use with --das3 is not
  encouraged as it would put modules into prod/common/epics and
  this would conflict with configure/RELEASE paths that do not
  have */epics/* in them...
parent cb344516

plan/vtwin-bootstrap-plan.md

+12 −10
Original line number Diff line number Diff line
@@ -58,15 +58,17 @@ existing `ROLE` derivation, `ROLE=vtwin`. The `ProcServ.getName()` logic in 
convention to derive `bl4b-ProcServ-vtwin1` as the managing IOC name — they

agree perfectly.



**Implication:** naming a fresh VM `bl4b-vtwin1`, `bl4b-vtwin2`, `ref-l-vtwin1`,

**Implication:** naming a fresh VM `bl4b-vtwin1`, `bl4b-vtwin2`, `bl4a-vtwin1`,

`bl3-vtwin9`, etc., will route every step of the bootstrap to the right

beamline's `${beamline}-ProcServ-${hostid}` IOC without any parameter changes.

This is the key "configure-by-hostname" property the plan must preserve.



**Preserve also:** the `slowcontrols_developers` GID pinning at 55121 (already

in use on bl4b-vtwin1). Establish this as a fixed GID in the `dependencies`

**Preserve also:** the `slowcontrols_developers` GID pinning at 43647 (used on

real instruments - currently 55121 on bl4b-vtwin1 but sub-optimal).

Establish this as a fixed GID in the `dependencies`

target so newly created `/home/controls/*` files survive replication to sibling

machines.

machines. Likewise, the `controls` UID shall be pinned to 88888 (used on real

instruments - currently 166 on bl4b-vtwin1 but sub-optimal).



---
@@ -76,7 +78,7 @@ machines. 


| Component                                       | State                                  |

|--------------------------------------------------|----------------------------------------|

| Rocky 9.7, `controls` user (uid 166), group 55121 | ✓                                      |

| Rocky 9.7, `controls` user (uid 166), group 55121 | x (sub-optimal see above)              |

| `/etc/profile.d/controls.sh` + sourced `00/01/02/10_*.sh` | ✓                               |

| `/home/controls/{share,bl4b,css,common,prod,var}` | ✓                                      |

| procServ 2.7.0-16.el9 (`/bin/procServ`)          | ✓                                      |
@@ -397,7 +399,7 @@ once against the aggregate set. 
6. **Retry once on authentication error** (HTTP 401) after re-prompting for

   password. This is the common failure mode on ORNL trac pushes.



7. **After all modules:** run `git-release.sh -e -r --all --das3 nED

7. **After all modules:** run `git-release.sh -r --all --das3 nED

   rel2.4.10_20241203` exactly once — this is the existing provision command,

   and it will now succeed because all nED's transitive deps are in place.
@@ -658,9 +660,9 @@ Failures should print the **exact** command to re-run to fix, not just "FAIL". 
   **true test** of "vanilla → virtual twin" and the proof that the plan is

   complete.



4. **Different beamline test:** rename VM to `ref-l-vtwin1`, clone bootstrap,

   run `make everything-vtwin`, verify the `ref-l-ProcServ-vtwin1` IOC and

   all `ref-l-*` applications come up. This proves the hostname-driven

4. **Different beamline test:** rename VM to `bl4a-vtwin1`, clone bootstrap,

   run `make everything-vtwin`, verify the `bl4a-ProcServ-vtwin1` IOC and

   all `bl4a-*` applications come up. This proves the hostname-driven

   scaling property.



5. **Regression test for the in-place vtwin:** make sure running the new
@@ -733,7 +735,7 @@ change the plan in minor but real ways. 
   specific config file)?



4. **The existing nED provision line.** The current

   `git-release.sh -e -r --all --das3 nED rel2.4.10_20241203` in the

   `git-release.sh -r --all --das3 nED rel2.4.10_20241203` in the

   `provision` target silently failed on this machine (leaving an empty

   `rel2.4.10_20241203/` dir). Should the new `epics-modules` target

   **replace** that line, or run *in addition* to it and just add the