SL1 PowerFlow Platform Release Notes, version 2.7.0

SL1 PowerFlow Platform version 2.7.0 includes updates and enhancements to the PowerFlow user interface, including a new Help Menu pane that provides Help content specific to that page, and an updated mappings dialog for SyncPacks that helps you quickly identify and sync items between SL1 and a third-party application like ServiceNow. This release also includes an updated Notifications button that displays on the top navigation bar, next to the Help button.

Features

This section covers the features that are included in SL1 PowerFlow Platform version 2.7.0:

  • Clicking the Help button now opens the Help Menu on the right-hand side of the PowerFlow user interface that provides Help content specific to that page. The Help Menu also includes a context-sensitive link to the relevant page in the product documentation.
  • Improved the mappings experience on the Configurations pane for PowerFlow applications, such as "Sync Devices from SL1 to ServiceNow", by adding a new modal that lets you easily locate and map the items you want to sync with PowerFlow. For more information, see Editing Mappings in a PowerFlow Application in the SL1 PowerFlow Platform manual.
  • Added a Notifications button to the top navigation bar, next to the Help button, which you can click to view a list of all notifications. This option was available on the user name menu in previous versions of PowerFlow. In addition, the Notifications button displays the number of current notifications.
  • Updated the way that logs display in the PowerFlow user interface to make the logs easier to read.
  • Made API key lookups more efficient to prevent authentication timeouts in high-scale environments.
  • Added the max_result_size environment variable to the docker-compose.yml file to organize the step result data into chunks of a specific size. For more information, see the Troubleshooting chapter in the SL1 PowerFlow Platform manual.
  • The following services are included in this release of PowerFlow:
    • contentapi. image: registry.scilo.tools/sciencelogic/pf-api:rhel2.7.0
    • couchbase. image: image: registry.scilo.tools/sciencelogic/pf-couchbase:6.6.0-10
    • dexserver. image: registry.scilo.tools/sciencelogic/pf-dex:2.22.0-5
    • flower. image: registry.scilo.tools/sciencelogic/pf-worker:rhel2.7.0
    • gui. image: registry.scilo.tools/sciencelogic/pf-gui:2.7.0-ubi7
    • pypiserver. image: registry.scilo.tools/sciencelogic/pf-pypi:6.3.1-11
    • rabbitmq. image: registry.scilo.tools/sciencelogic/pf-rabbit:3.8.35-3
    • redis. image: registry.scilo.tools/sciencelogic/pf-redis:6.2.14-3
    • scheduler. image: registry.scilo.tools/sciencelogic/pf-worker:rhel2.7.0
    • steprunner. image: registry.scilo.tools/sciencelogic/pf-worker:rhel2.7.0
    • syncpacks_steprunner. image: registry.scilo.tools/sciencelogic/pf-worker:rhel2.7.0

Issues Addressed

The following issues were addressed in this release:

  • For the powerflowcontrol (pfctl) command-line utility, renamed the existing collect_pf_logs action to logcollect and updated the entire functionality of the action. For more information, see the logcollect topic in the Using the powerflowcontrol (pfctl) Command-line Utility chapter in the SL1 PowerFlow Platform manual. (Case: 00317293) (Jira ID: EM-55798, INT-5844)
  • Updated Couchbase initialization scripts to handle a corrupted logs bucket when the upgrade to Couchbase 6.6.0 was interrupted. (Case: 00379571, 00391035) (Jira ID: INT-5852)
  • Added the pfctl node actions check_redis_maxmemory and fix_redis_maxmemory to verify the MAXMEMORY variable in the docker-compose.yml file. Before these updates, the PowerFlow Redis service expected a value of MAXMEMORY to be passed using Docker environment variables, but the override templates in the pfctl utility supplied maxmemory instead. The templates have been updated, and the new check_redis_maxmemory action determines if the Redis service requires an update to the environment variable, while the fix_redis_maxmemory action applies that change. The user will need to delete and recreate the Redis service after the fix action runs. In addition, the PowerFlow Redis image was updated to accept either MAXMEMORY or maxmemory as an environment variable. (Case: 00385354) (Jira ID: INT-5837)
  • Addressed an issue where the pfctl utility did not properly calculate Linux memory availability when running the pfctl healthcheck action. (Case: 00321182) (Jira ID: INT-5812)

Known Issues

This release contains the following known issues:

  • The journald volatile storage takes part of the memory based on the environment memory size, which might cause undesired behavior in environments where the memory is highly used by PowerFlow services. PowerFlow uses journald volatile storage, which means that all logs are kept only in memory. (Case: 00347339)

    Total Memory Maximum memory used by journald
    16 GB About 800 MB
    24 GB About 1.2 GB
    32 GB About 1.6 GB
    64 GB About 3.2 GB

    To check the size of journal logs on any PowerFlow version 2.2.x or later single node, run the following command:

    du -sh /run/log/journal

    For PowerFlow version 2.2.x, you can control those settings by updating the /etc/docker/daemon/json file and setting the log-opts max size in the json-file logging driver. For more information, see https://docs.docker.com/config/containers/logging/json-file/.

    For PowerFlow version 2.3 or later nodes, you can clear logs with the following command (this is automatically done when you run the healthcheck action):

    journalctl --vacuum-time=7d

    You can also configure journald logs settings by using the following command to enforce small size and time limits:

    sudo sed -i -e '/RuntimeMaxUse=/s/.*/RuntimeMaxUse=800M/' -e '/MaxRetentionSec/s/.*/MaxRetentionSec=2week/' /etc/systemd/journald.conf && sudo systemctl restart systemd-journald

    PowerFlow updates journald volatile limits to the following values, which can be changed if you want retain fewer or more logs:

    RuntimeMaxUse=800M

    MaxRetentionSec=2week

  • When upgrading to Couchbase version 6.6.0, the number of documents in the logs bucket could make the upgrade take longer, as a namespace upgrade is needed. ScienceLogic recommends that you flush the logs bucket if there are more than 300,000 documents that are taking up close to 2 GB of space in every node. Flushing the logs bucket will speed up the upgrade process. Otherwise, migrating a logs bucket of that size would take two to three minutes per node.

    Run the following command to flush the logs bucket after the PowerFlow version 2.6.0 RPM was installed, but before redeploying the PowerFlow Stack:

    pfctl --host <hostname><username>:<password> node-action --action flush_logs_bucket

    Alternately, you can flush the logs bucket manually using the Couchbase user interface.

  • If you get the "Error: No such option: --version Did you mean --json?" error message when running the pfctl --version command, you might have an older version of pfctl that was installed as a different user. To resolve this, be sure to install the powerflowcontrol (pfctl) utility version 2.7.7 as root with sudo, and remove any other versions installed by other users (isadmin or ec2-user): (Case: 00360512) 

    su isadmin

    pip3 uninstall -y iservicecontrol

  • For upgrades from PowerFlow version 2.2.x systems that have the localpkg_gpgcheck=1option enabled in /etc/yum.conf, the SL RPM Public Key is required. Please contact your ScienceLogic Customer Success Manager (CSM) or create a new Service Request case at https://support.sciencelogic.com/s in the "PowerFlow" category to request access to that key.
  • To avoid authentication issues, do not use the dollar sign ($) character as the first character in any of the passwords related to PowerFlow. You can use the $ character elsewhere in the password if needed.
  • In PowerFlow version 2.4.0 and later, if you enabled the latest authentication updates for the backend services, the RabbitMQ API is no longer available externally from the cluster. As a result, remote API requests directly to RabbitMQ might not work (the RabbitMQ user interface is still completely operational). As a workaround, if you require remote access to the RabbitMQ API, you can return to legacy behavior by setting the following gui environment variable: force_auth_validation: true. Alternatively, you may perform any api requests to rabbit directly from within the container. Remote RabbitMQ API access for internal authentication users will be enabled in a future release of PowerFlow.
  • The Workflow Health and Interconnectivity widget on the PowerFlow Control Tower page displays diagrams for PowerFlow applications and SyncPacks that have been deleted. To work around this issue, run the "PowerFlow Control Tower HealthCheck" application or wait for the next scheduled run of the application.
  • If your PowerFlow system uses self-signed certificates, you will need to manually accept the certificate before you can upload SyncPacks. Go to https://<IP address of PowerFlow>:3141/isadmin, accept the certificate, and then log into PowerFlow. After you log in, you will be able to upload SyncPacks.
  • The latest tag does not exist after the initial ISO installation. This situation only affects users with custom services that point to the latest tag. To work around this issue, run the tag latest script manually after running the ./pull_start_iservices.sh command:

python /opt/iservices/scripts/system_updates/tag_latest.py /opt/iservices/scripts/docker-compose.yml

System Requirements

The PowerFlow platform does not have a specific minimum required version for SL1 or AP2. However, certain SyncPacks for PowerFlow have minimum version dependencies, which are listed on the Dependencies for SL1 PowerFlow SyncPacks page.

Ports

The following table lists the PowerFlow ingress requirements:

Source Port Purpose

SL1 host

443

SL1 run book actions and connections to PowerFlow

User client

3141

Devpi access

User client

443

PowerFlow API

User client

5556

Dex Server: enable authentication for PowerFlow

User client

8091

Couchbase Dashboard

User client

15672

RabbitMQ Dashboard

User client

22

SSH access

The following table lists the PowerFlow egress requirements:

Destination Port Purpose

SL1 host

7706

Connecting PowerFlow to SL1Database Server

SL1 host

443

Connecting PowerFlow to SL1 API

Additional Considerations

Review the following list of considerations and settings before installing PowerFlow:

  • ScienceLogic highly recommends that you disable all firewall session-limiting policies. Firewalls will drop HTTPS requests, which results in data loss.
  • Starting with PowerFlow version 3.0.0, the minimum storage size for the initial partitions is 60 GB. Anything less will cause the automated installation to stop and wait for user input. You can use the tmux application to navigate to the other panes and view the logs. In addition, at 100 GB and above, PowerFlow will no longer allocate all of the storage space, so you will need to allocate the rest of the space based on your specific needs.
  • PowerFlow clusters do not support vMotion or snapshots while the cluster is running. Performing a vMotion or snapshot on a running PowerFlow cluster will cause network interrupts between nodes, and will render clusters inoperable.
  • The site administrator is responsible for configuring the host, hardware, and virtualization configuration for the PowerFlow server or cluster. If you are running a cluster in a VMware environment, be sure to install open-vm-tools and disable vMotion.
  • You can configure one or more SL1 systems to use PowerFlow to sync with a single instance of a third-party application like ServiceNow or Cherwell. You cannot configure one SL1 system to use PowerFlow to sync with multiple instances of a third-party application like ServiceNow or Cherwell. The relationship between SL1 and the third-party application can be either one-to-one or many-to-one, but not one-to-many.
  • The default internal network used by PowerFlow services is 172.21.0.1/16. Please ensure that this range does not conflict with any other IP addresses on your network. If needed, you can change this subnet in the docker-compose.yml file.

For more information about system requirements for your PowerFlow environment, see the System Requirements page at the ScienceLogic Support site at https://support.sciencelogic.com/s/system-requirements.

Installing or Upgrading PowerFlow

For detailed steps about installing or upgrading to this version of PowerFlow, see Installing and Configuring PowerFlow.

You should always upgrade to the most recent release of PowerFlow.