SL1 PowerFlow Platform Release Notes, version 3.1.0

SL1 PowerFlow Platform version 3.1.0 addresses several issues and adds multiple user interface improvements for PowerFlow, including indicators for the number of schedules for an application, a persistent footer at the bottom of PowerFlow with system information, and an "Export to CSV" option for SyncPacks.

Features

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

  • Added endpoints for accessing PowerFlow API documentation. For more information, see the API Endpoints in SL1 PowerFlow chapter in the PowerFlow manual.
  • Updated the user interface for scheduled applications so that if multiple schedules exist, they have a green badge in the top right corner indicating the number of schedules.
  • Added a new persistent footer to PowerFlow that displays system information, including a last login timestamp and the PowerFlow version.
  • The active version of a SyncPack is now displayed separately from the other versions on the SyncPacks page.
  • Added an "Export to CSV" option to the SyncPacks page that lets you view a CSV file with the list of SyncPacks and relevant information about them.
  • Updated the Celery healthcheck command to work with Celery 4 and Celery 5.
  • Updated PowerFlow services to use a new version of the Couchbase SDK, which works with Python 3.11.

As a result of this change, upgrading to version 3.1.0 of PowerFlow may break some custom SyncPacks that currently use old versions of the Couchbase SDK directly. For more information, see the  Considerations for Custom Syncpacks with PowerFlow 3.1.0 and Later chapterin the PowerFlow manual.

  • You can now use the worker_prefetch_multiplier value in the the docker-compose.yml file to change how many steps the steprunner workers will reserve for use. The lower this value is, the lower the number of tasks reserved. The value must be an integer greater than or equal to 0.

For example, if there is a long-running task that takes 20 minutes to complete, the worker may reserve four tasks on the queue to run, but the worker will not get to the task until the 20-minute task has completed. Since the extra four tasks can run independently of the 20 minute task, you could set worker_prefetch_multiplier to 1 instead. These four tasks could instead be picked up by other steprunners, asthey are not reserved.

The default value is 4. ScienceLogic does not recommend setting the value to 0, because workers will continually consume the messages.

  • Updated the message that displays when a conditional step is not connected to an output step to read "To proceed with adding a new condition, please make sure that at least one output step is connected to this Conditional Step."
  • The Flower user interface no longer exposes the Monitor tab due to Flower2 generating Prometheus metrics. PowerFlow does not expose those metrics, as most of that information is already displayed in the Control Tower user interface.

If you want to configure the metrics from Flower and display them in Grafana, see the Flower documentation about the Prometheus integration at https://flower.readthedocs.io/en/latest/index.html

  • The following images are included in this release of PowerFlow:
  • registry.scilo.tools/sciencelogic/pf-api:rhel3.1.0
  • registry.scilo.tools/sciencelogic/pf-couchbase:6.6.0-12
  • registry.scilo.tools/sciencelogic/pf-dex:2.37.1-9
  • registry.scilo.tools/sciencelogic/pf-worker:rhel3.1.0
  • registry.scilo.tools/sciencelogic/pf-gui:3.1.0
  • registry.scilo.tools/sciencelogic/pf-pypi:6.3.1-13
  • registry.scilo.tools/sciencelogic/pf-rabbit:3.8.35-5
  • registry.scilo.tools/sciencelogic/pf-redis:6.2.14-4

Issues Addressed

The following issues were addressed in this release:

  • Addressed an issue that prevented the remaining applications, configurations, and steps from a previous SyncPack version from being deleted when the SyncPack is upgraded. (Case: 00442674)  (Jira ID: INT-6143)

  • When importing a SyncPack into PowerFlow, the host_address field in the isconfig.yml file will now be converted to all lowercase by PowerFlow. (Case: 00439319) (Jira ID: INT-6142)

While PowerFlow will make this change automatically, ScienceLogic still recommends manually setting the host_address to lower case.

  • Added two new parameters to the "Backup" application in PowerFlow:

    • verify_cluster. Use to verify Couchbase Cluster Health Status.

    • create_report. Use to create a report of the content bucket document IDs that were backed up. This only works if the verify_cluster parameter is enabled and the cluster is healthy. (Case: 00416830) (Jira ID: INT-5956)

The verify_cluster option must not be disabled. If disabled, incomplete backups can be created in Cluster Environments if the Cluster is unhealthy.

  • Updated the OL8 upgrade scripts to allow use of a custom repository configuration file, which can contain proxy configurations or other custom configurations. For more information, see the Considerations if Upgrading Using Proxies section in the PowerFlow manual. (Case:00435849) (Jira ID: INT-6130)

  • Updated the error messages in the compose_override.sh script to more clearly display so that docker-compose.yml or docker-compose-override.yml files can be updated as expected. (Case: 00412686) (Jira ID: INT-5945)

  • You can now install the RPM file in cloud environments without using PIP_NO_INDEX=true.

  • Addressed an issue that prevented JSON configuration values from being set to null or empty.

  • Updated RabbitMQ shutdown behavior so that node1 is always the last node to shutdown and leave the cluster. Additionally, increased the startup delays for node2 and node3 to 40 and 80 to allow node1 more time to properly start up.

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 75 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.0/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.

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)

  • To check the size of journal logs on a single PowerFlow node, run the following command:

    du -sh /run/log/journal

    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 (PowerFlow later than 2.6.0) from PowerFlow versions earlier than 2.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 RPM is 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 3.0.7 or later 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

  • To avoid authentication issues, do not use the dollar sign ($) character in any part of passwords related to 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

Installing or Upgrading PowerFlow

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

Starting with version 2.3.0, all PowerFlow platform releases are suitable for both MUD and non-MUD systems.

Due to the upcoming end of support for Oracle Linux 7, ScienceLogic strongly urges users to upgrade to Oracle Linux 8 (OL8). As such, only the OL8-based package and upgrade path is defined and provided. If you have extenuating circumstances and want to obtain an OL7-based install for PowerFlow 3.1.0, please contact your CSM or ScienceLogic support.

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