How do I configure an NSP Workflows trigger framework?

Purpose

Use this procedure to install or uninstall a WFM framework. The WFM Trigger framework enables you to trigger workflows from an external system such as Git or HTTPS, without the need for NSP Workflows to monitor the external system directly.

The framework provided by NSP installs a single microservice that can handle at least one user -provided plugin installed into that microservice. The framework handles connections to the internal Kubernetes environment and to NSP Workflows, while the plug-in connects to the external system. The plugin must include a specified Python file to allow it to push to a Kafka topic in the NSP. From there, a Kafka Trigger can be created in NSP Workflows to trigger a workflow.

You can configure as many microservices as required, with different parameters. container images and Helm charts are provided in the Nokia Git repository.

This procedure provides general information. See the WFM Trigger Framework tutorial on the Network Developer Portal for more details.

Container image

You will need to use a container image generated from the base container image provided by NSP, that includes the code written to handle the external system. The name of the base image can be found either by browsing the NSP container repository or by looking at the provided defaulted values.yaml file.

Helm charts

A default values.yaml file is provided, and new values.yaml files must be derived from this one to get all the appropriate NSP-specific information that the pod needs to run.  You need to change the following values:

  • pod_name:  Each pod must be given a unique pod name to avoid clashes over resources and so to install properly.

  • topic_name:  This specifies the topic name that messages will be sent on (and thus that the Kafka Trigger must listen on).   The topic will always be wfm.trigger.<topic_name>.  If this is not given, the pod_name will be used as the topic name.

  • pluginConfigFileName:  The file name of any config file that the user happens to be using.  If this is not set, it defaults to plugin.conf.

  • pluginConfigFileInstallPath:  The install path of the config file.  If this is not set, it defaults to /opt/nsp/configure/config.

  • pluginPythonClientFile:  The name and path of the client file that's importing the framework_server_client.  If this is not set, it defaults to /opt/nsp/launch_python_app.py.

  • pluginCertsFileName:  The file name for any certs that are being used.  If this is not set, it defaults to plugincert.pem.

  • pluginCertsInstallPath:  The install path for any certs that are being used.  If this is not set, it defaults to /opt/nsp.

Steps
Perform Helm installation
 
1 

Log in as the root user on the NSP cluster host.

2 

Open a console window.

3 

Execute the Helm installation based on the following example:

# helm install Helm_name Helm_path-f values_file --set-file pluginCertsFile= certs_file --set-file pluginConfigFile=plugin_file ↵

where

Helm_name is the identifier of the Helm_chart

Helm_path is path to the Helm chart

values_file is the path to the values.yaml file

certs_file is the path to and filename of the certs file

plugin_file is the path to and filename of the plugin file

If you do not want to copy certs files to the pod, the --set-file pluginCertsFile flag is not required.

Perform Helm uninstallation
 
4 

To uninstall a framework, you must delete them using Helm. Execute the following:

# helm uninstall Helm_name --namespace namespace -n $(kubectl get pods -A | awk '/Helm_name/ {print$1;exit}') ↵

where

Helm_name is the framework Helm chart identifier

namespace is the Kubernetes namespace

5 

Close the console window.

End of steps