EOP-126: Review of Momentum tech specs (#762)

Signed-off-by: Doug Koerich <[email protected]>

.github/workflows/labeller.yml

@@ -6,9 +6,10 @@ on:
 jobs:
   triage:
     runs-on: ubuntu-latest
-    runs:
-      using: 'node16'
     steps:
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '16.x'
       - uses: actions/labeler@v2
         with:
           repo-token: '${{ secrets.GITHUB_TOKEN }}'

content/momentum/4/4-cluster-config-failover.md

@@ -1,15 +1,13 @@
 ---
-lastUpdated: "03/26/2020"
+lastUpdated: "05/21/2024"
 title: "Configuring Momentum for High Availability and Failover"
-description: "Momentum's architecture supports fault tolerant configurations This means that you can operate in an environment that is readily configured to support failing over automatically Components that support high availability and fault tolerance include the following ecconfigd Dura VIP™ bindings Centralized logging and Aggregration Per node data Per node logs can..."
+description: "Momentum's architecture supports fault tolerant configurations This means that you can operate in an environment that is readily configured to support failing over automatically"
 ---
 
 Momentum's architecture supports fault-tolerant configurations. This means that you can operate in an environment that is readily configured to support failing over automatically.
 
 Components that support high availability and fault tolerance include the following:
 
-*   [`ecconfigd`](/momentum/4/conf-overview#conf.ecconfigd)
-
 *   [DuraVIP™ bindings](/momentum/4/4-cluster-config-duravip)
 
 *   [Centralized logging and Aggregration](/momentum/4/log-aggregation)
@@ -22,4 +20,4 @@ Components that support high availability and fault tolerance include the follow
 
 *   [cidr_server](/momentum/4/4-cluster-cidr-server) and [as_logger](/momentum/4/modules/as-logger)
 
-    The **cidr_server** queries the data created by an as_logger module and displays the result in the cluster console. The **cidr_server** and as_logger can be configured to log data to a SAN. Locking semantics must be checked.
+    The **cidr_server** queries the data created by an as_logger module and displays the result in the cluster console. The **cidr_server** and as_logger can be configured to log data to a SAN. Locking semantics must be checked.

content/momentum/4/4-cluster.md

@@ -1,18 +1,14 @@
 ---
-lastUpdated: "03/26/2020"
+lastUpdated: "05/21/2024"
 title: "Cluster-specific Configuration"
-description: "Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus A cluster is comprised of at least one Manager node and one or more MTA nodes The Manager in the cluster will be your central point of management for the..."
+description: "Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus A cluster is comprised of at least one Manager node and one or more MTA nodes"
 ---
 
 
 Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus. A cluster is comprised of at least one Manager node and one or more MTA nodes. The Manager in the cluster will be your central point of management for the cluster. Ideally, a cluster will have a dedicated gigabit network for transmission of replicated data and internal message moves.
 
 The clustering capabilities of Momentum enable the following features:
 
-*   Centralized management of configuration for multiple MTA nodes
-
-*   Replicated, redundant, configuration repository with revision control
-
 *   Log aggregation pulling log files from MTA nodes to centralized location(s) on the network
 
 *   Replication of a variety of real-time metrics to allow cluster-wide coordination for inbound and outbound traffic shaping
@@ -47,49 +43,6 @@ For general information about Momentum's configuration files, see [“Configurat
 
 For additional details about editing your configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
 
-### <a name="cluster.config_files.mgmt"></a> Cluster-specific Configuration Management
-
-Momentum configuration files are maintained in a version control repository and exported to your cluster network via the [`ecconfigd`](/momentum/4/conf-overview#conf.ecconfigd) service running on the cluster manager. This daemon is auto-configuring and will replicate your configuration repositories to all participating cluster nodes. On the cluster manager, the repository resides in the `/var/ecconfigd/repo` directory. Nodes pull their configuration from this repository and store their working copy in the `/opt/msys/ecelerity/etc/conf` directory.
-
-The default installation has a cron job deployed on the nodes that uses [**eccfg pull**](/momentum/4/executable/eccfg) to update the local configuration from the `ecconfigd` service. **eccfg** is built in such a way that these updates are applied atomically to the configuration checkout directory.
-
-The tools that operate on the configuration checkout directory try very hard to avoid leaving it in a broken state. Every minute, each node will attempt to update its directory to match the repository. If you have made local changes to the directory, the update will attempt to merge updates from the repository with your changes. The update process will only modify the directory if the complete revision was able to be pulled. In other words, it will not modify the configuration checkout directory if doing so causes a conflict and will never leave a directory with a half-applied update.
-
-In some situations, it is possible to put the configuration replication into a conflicted state. For instance, in a two node cluster, if one of the nodes is unplugged from the network while configuration changes are made and committed on both nodes, when the network cable is re-connected, the configuration will attempt to sync but will notice that conflicting changes have been made. If conflicting changes were found, `ecconfigd` will warn you and provide you with instructions on how to resolve the conflict. You may need to manually resolve the conflicting configuration files. For instructions on changing configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
-
-**<a name="cluster.config_files.mgmt.cluster"></a> 16.1.1.1. Repository Working Copy for Cluster**
-
-On the client side of the configuration management, each node has a working copy checkout of the repository located at `/opt/msys/ecelerity/etc/conf`. The following are descriptions of the subdirectories in a cluster configuration:
-
-*   `global` – location for sharing cluster-wide configuration information between nodes
-
-    Every node has access to this subdirectory.
-
-*   `default` – contains your default configuration files, which are shared across multiple nodes
-
-    `default` is the name of the default subcluster and represents the default configuration for nodes in that subcluster.
-
-*   *`nodename`* – contains node-specific configuration files
-
-    When you create a node-specific configuration file, a directory bearing the node name and a node-specific `ecelerity.conf` file are created on *all* nodes in the cluster.
-
-    When nodes use common values for a number of options, if you wish you can put these options in a configuration file stored in the `global` directory rather than repeating them in each /opt/msys/ecelerity/etc/conf/*`nodename`*/ecelerity.conf file. However, you must add include statements to the /opt/msys/ecelerity/etc/conf/*`nodename`*/ecelerity.conf file on each node.
-
-*   *`peer`* – any files shared by multiple nodes in a single subcluster
-
-By default the order is:
-
-```
-/opt/msys/ecelerity/etc
-/opt/msys/ecelerity/etc/conf/global
-/opt/msys/ecelerity/etc/conf/{NODENAME}
-/opt/msys/ecelerity/etc/conf/default
-```
-
-Directories are separated by the standard path separator.
-
-If you wish to change the search order, set the environment variable `EC_CONF_SEARCH_PATH`. For more information about `EC_CONF_SEARCH_PATH`, see [*Configuring the Environment File*](/momentum/4/environment-file) .
-
 ### <a name="cluster.config_files.local.include"></a> Using Node-local `include` Files
 
 If you have any configurations specific to a particular node, fallback values for configuration options in that node-local configuration file *cannot* be included via the `/opt/msys/ecelerity/etc/conf/ecelerity.conf` file. For an included file, the parent file's path is added to the search path, so if a file is included from `/opt/msys/ecelerity/etc/conf/default/ecelerity.conf`, the search path becomes:
@@ -109,4 +62,4 @@ Set `OPTION` in a `node-local.conf` file in all the /opt/msys/ecelerity/etc/conf
 
 Add an "include node-local.conf" statement to `/opt/msys/ecelerity/etc/default/ecelerity.conf`.
 
-If there are major differences between node configurations, it is probably simpler to create a separate configuration file for each node as described in [“Repository Working Copy for Cluster”](/momentum/4/4-cluster#cluster.config_files.mgmt.cluster).
+If there are major differences between node configurations, it is probably simpler to create a separate configuration file for each node as described in [“Repository Working Copy for Cluster”](/momentum/4/4-cluster#cluster.config_files.mgmt.cluster).

content/momentum/4/4-implementing-policy-scriptlets.md

@@ -1,7 +1,7 @@
 ---
-lastUpdated: "03/26/2020"
+lastUpdated: "05/21/2024"
 title: "Policy Scriptlets"
-description: "Lua scripts provide you with the capability to express the logic behind your policy Aside from being very convenient policy scripts can be reloaded on the fly allowing real time adjustment of policy without interrupting service the Momentum implementation has extremely low overhead and tightly integrates with the event based..."
+description: "Lua scripts provide you with the capability to express the logic behind your policy Momentum implementation has extremely low overhead and tightly integrates with the event based architecture"
 ---
 
 Lua scripts provide you with the capability to express the logic behind your policy. Aside from being very convenient (policy scripts can be reloaded on the fly, allowing real-time adjustment of policy without interrupting service), the Momentum implementation has extremely low overhead and tightly integrates with the event-based architecture, being able to suspend processing until asynchronous operations (such as DNS resolution, or database queries) complete. Note that variables used in a policy script are scoped locally and only persist in the particular policy script in which it is defined. Use the [validation context](/momentum/4/4-policy#policy.validation) to persist data over different policy phases and policy scripts.
@@ -106,31 +106,19 @@ In the `default_policy.conf` file, you should also enable the datasource(s) suit
 
 ### <a name="policy.best.practices"></a> Creating Policy Scripts
 
-Following best practices when creating policy scripts is important, especially in a cluster environment when scripts are used on more than one node. Scripts should take advantage of Momentum's built-in revision control and be added to the repository using the [eccfg](/momentum/4/executable/eccfg) command.
+Following best practices when creating policy scripts is important, especially in a cluster environment when scripts are used on more than one node.
 
 To create a policy script, perform the following:
 
-1.  Take steps to avoid conflicts.
-
-    When working with files that are under revision control, it is important to take steps to avoid conflicts with changes made elsewhere in the system and to be able to track changes. For this reason, perform the following actions before creating any policy scripts:
-
-    *   Provision a user account for each admin user, so that the history in the repository is meaningful.
-
-    *   Ensure that you have the latest updates on the node where you are creating the scripts by running **`/opt/msys/ecelerity/bin/eccfg pull`**      .
-
-        ### Note
-
-        Pay special attention to the instructions for using the **pull** command—if the configuration is updated your current directory may be invalidated. For more information, see [eccfg](/momentum/4/executable/eccfg).
-
-2.  Create a directory for your script.
+1.  Create a directory for your script.
 
     Scripts should be created in a directory that is under revision control. Create a directory for your scripts in the working copy of the repository on a node where you intend to run the script:
 
     *   If your scripts apply to all nodes in the cluster, create this directory under the `/opt/msys/ecelerity/etc/conf/default` directory or store them in the `global` directory. Typically, policy scripts are saved under Momentum's default working copy directory `/opt/msys/ecelerity/etc/conf/default/scripts`.
 
     *   If your scripts apply to only one node, create a node-specific directory.
 
-3.  Write your script.
+2.  Write your script.
 
     All scripts must
 
@@ -175,7 +163,7 @@ To create a policy script, perform the following:
 
     These messages indicate a scriptlet error and give both the name of the script and the callout that failed.
 
-4.  Update your configuration to properly reference your script.
+3.  Update your configuration to properly reference your script.
 
     After writing a script and saving it to the repository, you must include it in the [`scriptlet`](/momentum/4/modules/scriptlet) module using a `script` stanza in your `ecelerity.conf` file.
 
@@ -219,7 +207,7 @@ To create a policy script, perform the following:
 
     For additional details about editing your configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
 
-5.  Check the validity of your script.
+4.  Check the validity of your script.
 
     Since a malformed configuration file will not reload, using **config reload**        is one way of validating your scriptlet syntax. After your configuration has been changed, issue the command:
 
@@ -244,7 +232,7 @@ To create a policy script, perform the following:
 
     However, please note that Message Systems does not provide support for the use of any third party tools included or referenced by name within our products or product documentation; support is the sole responsibility of the third party provider.
 
-6.  Debug your script.
+5.  Debug your script.
 
     Successfully reloading the configuration file does not guarantee that your script will run. Your script may be syntactically correct but have semantic errors. As always, you should test the functionality of scripts before implementing them in a production environment.
 
@@ -288,24 +276,6 @@ To create a policy script, perform the following:
           note="No email received at this address", code="550"}
         ```
 
-7.  Commit your changes.
-
-    Once you are satisfied that your scripts function correctly, commit your changes. From the directory above your newly created directory, use **eccfg** to add both the directory and the script to the repository:
-
-    *   If you are adding a new script, issue the command
-
-        **eccfg commit ––username *`admin_user`* ––password *`passwd`* ––add-all --message *`message here`***                                                                                             .
-
-    *   If you are editing a script, you need not use the `––add-all` option.
-
-8.  Repply your changes, if required.
-
-    In all cases, edits made to the local configuration will need to be manually applied to the node via **config reload** . The **eccfg commit**        command will not do it for you. If you have not reloaded your configuration, issue the console command:
-
-    **`/opt/msys/ecelerity/bin/ec_console /tmp/2025 config reload`**                         
-
-    If your changes affect more than one node, each node will check for an updated configuration each minute and automatically check out your changes and issue a **config reload** .
-
 ### <a name="policy.scriptlets.examples"></a> Examples
 
 This section includes examples of using policy scripts.
@@ -336,4 +306,4 @@ Use `msg.priority` to read the priority of a message.
 
 ### Note
 
-It is important not to overuse the priority setting. High priority messages should be reserved for messages that need to go out immediately, before other messages. Keeping high priority messages to a low percentage of the total message volume is important so the high priority messages do not cause delays for normal priority messages. A common use case for high priority messages is sending out password resets in the midst of a major mail campaign.
+It is important not to overuse the priority setting. High priority messages should be reserved for messages that need to go out immediately, before other messages. Keeping high priority messages to a low percentage of the total message volume is important so the high priority messages do not cause delays for normal priority messages. A common use case for high priority messages is sending out password resets in the midst of a major mail campaign.

content/momentum/4/4-preface.md

@@ -1,7 +1,7 @@
 ---
-lastUpdated: "03/27/2020"
+lastUpdated: "05/21/2024"
 title: "Preface"
-description: "Certain typographical conventions are used in this document Take a moment to familiarize yourself with the following examples Text in this style indicates executable programs such as ecelerity Text in this style is used when referring to file names For example The ecelerity conf file is used to configure Momentum..."
+description: "Certain typographical conventions are used in this document Take a moment to familiarize yourself with the following examples"
 ---
 
 ## <a name="typographical"></a> Typographical Conventions Used in This Document
@@ -37,5 +37,5 @@ The preceding line would appear unbroken in a log file but, if left as is, it wo
 
 Where possible, Unix command-line commands are broken using the ‘`\`’ character, making it possible to copy and paste commands. For example:
 
-/opt/msys/ecelerity/bin/eccfg bootstrap --clustername *`name`* --username=admin \
-    --password=*`admin cluster_host`*
+sudo -u ecuser \
+    /opt/msys/ecelerity/bin/ec_show -m *`msg-id`*