This project is about constructing and automating the instantiation of virtual twin systems for ORNL/SNS+HFIR instrument control systems.
Previous work has been done to [setup images](https://trac.sns.gov/trac/slowcontrols/wiki/image2instance%20) on the ORNL Research Cloud. The instructions assume a "bootstrap" image that is already constructed.
We wish to develop a set of instructions that will take a "vanilla" machine install and transform it into a suitable "virtual twin" that operates with all the abilities of a beamline system with minimal effort.
## Prompt 1
You are working in the tasking project, blxx-vtwin-construction branch. The machine you are running has already been manually improved to be a "twin" of the instrument SNS/BL4B/REF_L control system. The transformation is only partially complete. The goal of this session is to extract all the relevant parts of the configuration and software of this machine to develop a script that can transform a 'vanilla' VM image into a functional instrument control computer that can run all parts of the instrument control system. The repository that defines what should run on an instrument control system is located in "/home/controls/${BEAMLINE}/". There is a module in ~/bootstrap that has been developed to help with some of the configuration aspects, but it is currently incomplete. Some of the missing items are:
1. no thinlinc setup. Thinlinc is a fundamental capability to enable remote acess and a desktop environment on the machine needed to make the machine operate as an Operator Interface (OPI). Details on configuring thinlinc have been described in the [trac slowcontrols wiki](https://trac.sns.gov/trac/slowcontrols/wiki/image2instance%20).
2. no automated css (phoebus, scan server) setup. A repository for this is present in '/home/controls/css/' (and there is a vtwin branch).
3. no comprehensive IOC build+installation. The IOCs in "/home/controls/${BEAMLINE}/applications/*" all have fairly "regular" methods by which their dependencies are resolved. The best example is the "${BEAMLINE}-Det-nED" IOC (located at "/home/controls/${BEAMLINE}/applications/${BEAMLINE}-Det-nED/"). This IOC uniquely has a 'Makefile' with a 'dependencies' target. Study this IOC carefully as it holds the key in automating the automatic EPICS module dependency build and preparation of all IOCs.
4. no ability to "re-register" IOCs from the "${BEAMLINE}-ProcServ-*" configuration. An IOC runs from a procserv process that is managed by the script "/home/controls/share/scripts/ioc". That script creates and manages systemd service files. Given a beamline repository (always extracted to "/home/controls/${BEAMLINE}/") it should be possible to "regenerate" the needed systemd scripts and cause them to run.
Please review the current state of this machine as an incomplete representation of a "virtual twin" for the bl4b beamline that has some part of the above steps 1-3 performed, but not any of step 4 (running 'ioc status' gives "[no ProcServ PVs]" indications for all IOCs). Please develop a comprehensive plan to update the ~/bootstrap module such that it can run on a 'vanilla' VM image and transform it into a working "virtual twin" of a beamline. Observe how the beamline name (bl4b in the current embodiment) is encoded in the 'hostname'. This is important. It allows for scaling the automation simply by naming the instance appropriately. Ensure that actions are idempotent. Be resourceful. If you need me to execute commands, I can do so, as needed. You may install whatever you need, but please keep a record of it in the 'dependencies' target, again so that we can always go from a "vanilla" VM to a working "virtual twin" of the instrument simply by instantiating and naming the image appropriately.
