Override baseline scripts with project versions

Detailed Description

Following the paradigm of "no changes in the install root", there is currently no way to modify/override the baseline scripts that control important aspects of the system that customers and projects teams are required to modify.

We delivered assert plugins circa ES22, which allows net-new scripts and applications to start and stop with services.

However, we need the ability to interfere with baseline start/stop scripts.

Specific Use Cases;

1. Ability to modify the startup command line parameters of an existing baseline service
   e.g. Modify baseline realtime\run_processes.csc to prevent the connection controller process from switching comm paths

2. Starting front end processors for custom protocols
   These are tied to Omnicomm startup, and many would need individualised command line parameters that are linked to how the omnicomm processes are started/configured. Might just be a sub-item from #1, as the custom startup script could read the same RTDB config on its own, i.e. no need to interleave custom commands in the existing Omnicomm startup scripts/logic

3. OPC.assert.csc and OPC.shutdown.csc - details not provided

4. DPP.run_processes.csc. - details not provided

Preserving modifications, and adhering to the "no changes to INSTALLROOT" must be followed.

Scripts control the startup of the product, among other things, and are regularly modified by project teams who are adding/changing custom applications.

Other AVEVA applications that are installed via MSI also need a way to tie into these scripts in a support manner.

Assumptions

It is not clear from some comments from Chris B if this needs to be any more complicated than simple precedence already in place for binaries, libraries and config files.

There could be a complication without these scripts call each other. I.e., if a modified baseline script in the data root needs to call other baseline scripts, how to they do that? Also the reverse: how does a baseline script know to call the modified version?

Dependencies

There are future features around script signing that may complicate this design.

OASYS-327 "Speed-up Hot-Assertion scripts to decrease failover time"

PSR - Performance, Scalability, Resilience

There is already an arch backlog item to increase the performance of scripts.

Otherwise, this feature is not expected to decrease the performance. Rather, the stability of the system after an upgrade is improved.

NFR - Non-Functional Requirements

One of the linked defects highlights that the doc should clearly indicate that the folder structure should exactly mirror the baseline, and that this isn't the case after the configTool runs. The doc should clearly indicate how to copy the baseline script (if that is the solution) into the proper folder structure in the DATA root.

The upgrade process should notify users if it detects custom versions of scripts that have changed in the upgrade.

Links