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;
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
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
OPC.assert.csc and OPC.shutdown.csc - details not provided
DPP.run_processes.csc. - details not provided
Examples of use-cases that would be out of scope
Disabling baseline applications from starting
This is currently supported in baseline via the “RealTime_SelectiveStartup.json” file
Ability to execute a command/start an application on assert
In ES2022, this was made into a pluggable binary to speed up assertion on failovers/modeswitch, with documentation on how to write your own plugins
Ability to change the order or timing of the baseline startup sequence
There is a perceived risk of allowing this which may lead to system instability.
Acceptance Criteria
After fresh install of the product, use the new method to modify start-up scripts.
Observe that the overridden/modified scripts runs only once (c.f. ADO# 402875).
Confirm that these modifications survive an upgrade with little or no manual intervention.
It is not required to make backups of the customisations before the upgrade
The baseline scripts in the install root are not modified (c.f. ADO# 1224579)
Business Value
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.
Target Version
Enterprise SCADA 2022-R2 (stretch), Enterprise SCADA 2023 (must)
ENB are on 2020 and 2021
GRT are on 2021
This will be required by practically every new 2021+ customer.
Customer, Project, and Deadline Details
n/a Projects are modifying these scripts today.
Customers System / Architecture
- Size: Small, Med, and Large
- Topology: Single site, Multi Site, and Enterprise
- Any Unique configuration to note?: no.
- Has this functionality been delivered before?: no.
Out of Scope
None.
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.
Risks/Mitigations
This is seen as a way to reduce risk for upgrades.
Mock-up / Supporting Information
None.
Architecture Review
This will need arch design.
Do we need a SPIKE?
Likely, yes. Need to determine why it is that this doesn't work already...
Links
IMS Defects:
https://dev.azure.com/AVEVA-VSTS/Issue%20Management%20System/_workitems/edit/1224579
https://dev.azure.com/AVEVA-VSTS/OASyS/_workitems/edit/402875
Class 5 Estimate: https://dev.azure.com/AVEVA-VSTS/OASyS/_workitems/edit/1408209
Implementation: https://dev.azure.com/AVEVA-VSTS/OASyS/_workitems/edit/1503504
TechPubs:
