Help us improve your experience.
Let us know what you think.
Do you have time for a two-minute survey?
Help us improve your experience.
Let us know what you think.
Do you have time for a two-minute survey?
This section lists the known issues in Paragon Insights Release 4.3.0.
Paragon Insights Release 4.3.0 does not support offline installation on CentOS platforms.
Upgrading to Paragon Insights Release 4.3.0 fails on RHEL 8.2 and 8.3 platforms.
Workaround: Delete the healthbot_iagent.tar.gz file from the /var/local/healthbot/docker_images directory and retry upgrade.
If you are using Paragon Insights Release 2.x and want to upgrade to Release 3.x or Release 4.x with a multinode (Kubernetes) installation, you must install Paragon Insights afresh. To migrate your data from Paragon Insights Release 2.x (Docker Compose) to Release 3.x (Kubernetes) or Release 4.x (Kubernetes), follow the Migration from Paragon Insights Release 2.x to 3.x procedure. This issue does not arise if you are upgrading from Release 3.x to Release 4.x.
You cannot use the existing setup if you upgrade from Release 3.2 (Docker Compose) to Release 4.x. We recommend that you do not upgrade from Release 3.2 (Docker Compose) to Release 4.x.
You must re-create any user credentials that were present before upgrade from Release 3.x after you upgrade from Release 3.x to Release 4.x. This issue does not arise if you are upgrading from Release 4.x.
After you upgrade from Paragon Insights Release 3.x to Release 4.x, the dashboard configurations that you have saved in the earlier versions of Paragon Insights are not available. This problem doesn’t exist if you are upgrading from Release 4.x.
We don't provide documentation support for the Paragon Insights CLI. Contact a Juniper Networks representative for support.
If you deploy playbook instances back-to-back, the deployment may fail because of a database error. This is a rare scenario. As this is a timing issue, you can redeploy or roll back the configuration.
The time series database (TSDB) port is exposed by default in
Paragon Insights. If you need to shut down the TSDB port for security
reasons, you can use the healthbot tsdb stop-services command.
External API queries to TSDB do not need the TSDB port to be exposed.
However, if you use external tools such as Grafana, or if you need
to run a query to the TSDB directly (and not through APIs), the TSDB
port must be exposed.
In the absence of a time series database (TSDB) HA replication, if a Kubernetes worker node running a TSDB pod goes down, even though there is capacity in the pod, the TSDB service is not spun up on a new node. This is because a huge volume of data would need to be transferred to the new node.
Workaround: In the event of a failure of the server or storage hosting a TSDB instance, you can rebuild the server or damaged component.
Microservices fail to connect to PostgresSQL as PostgresSQL does not accept any connections during the primary role switchover. This is a transient state.
Workaround: Ensure that the microservices connect to PostgresSQL after the primary role switchover is complete.
Even though you click Cancel, the changes that you have made while editing a task will be saved.
You cannot reuse the name of a step that you have already deleted.
An error message will not be displayed even when you add a step with empty entries and click Save and Deploy.
Workaround: There is no known workaround.
SKU Name is removed from the Added Licenses section of the License Management page.