Pipeline is not editable as one of the previous deployment is in unresolved state but on the UI build completion is not visible
Import DeleteDeployment_20190211T095541_GMT.zip RAP into Deployment Manager instance.
Add this branch ruleset in your application rule.
Open DELETEDEPLOYMENT activity.
Run it by passing the problematic build ID(for example CH-13)
Once deletion happened remove the branch rule set from your application rule set.
Create a new deployment by updating the Deployment name in the below screen and proceed further to avoid conflict auto-generated deployment ID.
Unable to see existing pipelines in the landing page.
Ans:Below are the couple of root causes identified and resolution:
Root cause 1: pr_data_pipeline_configuration table may not be properly populated and/or DADT of Data-Pipeline-Configuration may not be updated.
Resolution: If upgarade happened from 4.1 to 4.2 or later, check whether pr_data_pipeline_configuration table exists and entries are present in it. Also check DADT for the class Data-Pipeline-Configuration is updated to point to pr_data_pipeline_configuration table.
Root cause 2: D_pxApplicationsWithPipelinedata page in the clipboard for which pxResults page is classless,This can be because DSS "datapage/newgenpages" is set to false
Resolution: Private edit the data transformpzGetApplicationsWithPipelinesand declare Primary.pxResults in Pages & Classes with class name as "Pipeline-Build-Status". And Launch the Deployment Manager again.Fix has been provided in Deployment Manager 4.3.2
My 8.1 orchestrator is very slow/un-responsive on cloud. What can I do ?
Ans: This could possibly be due to the Stream node being unresponsive. As a temporary workaround do the following. Create DSS EnableNextGenQueueProcessing with owning ruleset Pega-RulesEngine and set value as false.
Even if this works, we recommend following up with Pega Support to identify the root cause of the problem.
Guardrail compliance Error is observed while migrating RAP. Error says "Error in retreiving guardrail compliance score. Unauthorized access for the given parameter ID" How do I fix this?
Ans:Update the Access Group mentioned in the Pipeline to point to the correct version of Application.
On a 7.4 Orchestration system I have confirmed that my DMAppAdmin user and auth profile are correctly configured, but my orchestration system still fails to connect to managed systems.
Ans: There is a platform bug pre-8.1 which appends the port of 443 if you are using SSL. If the customer is using a load balancer, it could result in the IP address being added twice and the connection failing.
I am unable to receive email notifications from Pega Deployment Manager.
Ans: There could be a number of reasons why notifications are not working. Here are a few things to consider
Notifications for the 4.x series require a minimum Pega platform version of 8.1.3
Ensure that you have the correct email address in your operator record
Check to see if you are receiving notifications in the Notification gadget in Deployment Manager portal
Notifications will not work if the Stream Service is not running. There are couple of options here to consider
Ensure that the notifications Queue Processor is enabled
This can be fixed by going to Admin Studio portal, then navigate to Resources-->Queue Processors.
Ensure that the queue processor pyProcessNotification is enabled and running
If the previous step did not fix the problem, then the Stream service might need to be restarted
Resolved by starting Stream Service (Dev Studio-->Decisioning-->Infrastructure-->Services-->Stream).
Edit the settings to make sure Replication factor value does not exceed the number of nodes available.
Notifications will also not work on on nodes with an untyped Node classification. Ensure that the node type is Universal or at the very least Default. On 8.1.x there is a chance that the node type is set to Uptyped which can cause issues with Stream processing which is required for notifications to work properly
Trying to add the Developer portal to PegaDeploymentManager:Administrator results in the following error "pxDeploymentManagerStudio is not a Valid Record for use by this Rule". How can I fix this?
Ans : This error comes as you are trying to add the Developer portal to the access group from an operator, whose active access group, does have the Deployment Manager in the app stack as mentioned in the documentation on Adding the Dev Studio portal.
You can avoid this issue if you updated the access group using the DMReleaseAdmin operator.
Diagnostic checks are failing since the callback URL formed is different from the Orchestrator URL (URL redirection), however there doesn't seem to be anyway to update the Orchestrator callback URL. How can we resolve this issue ?
Ans: This often happens when the orchestrator URL somehow changed after the original DM setup either due to migrating the orchestrator to a separate environment or there was change to the resolved URL for that system.
For DM version 4.5 and earlier, there is no easy fix for this problem. This issue will however be fixed as part of Deployment Manager version 4.6. A Dynamic System Setting named Orchestrator URL will be provided which can be updated to point to the correct orchestrator system when running the pipeline. The recommendation here is to upgrade to 4.6 in order to address this problem.
What should we do when we encounter issues like ‘Authentication failures’ in case of orchestrator connecting to candidate or vice versa in the diagnostic checks ?
Ans: Often times the issue is due to incorrect configuration of the authentication profiles. Try the following suggested steps to address this issues
Check the password and userID mismatch of DMReleaseadmin and DMAppadmin authentication profile with the respective operators on the candidate and Orchestrator systems. Often times there are typos or mismatches in the passwords specified on any of those environments.
Check whether there is a VPN or firewall that restricts access to the target environment and ensure that the orchestrator environment IP ranges are whitelisted or accessible through the load balancer. Check this in both directions, from the target environment to the orchestrator and vice versa.
After upgrade deployment manager to 4.5, repository diagnostics is failing with error 'The artifact cannot be read from the repository'. How to resolve this issue ?
Ans: This issue is often seen if the candidate systems are in an older version of PegaDevOpsFoundation, such as when you are using the lastest version of Deployment Manager to manage pipelines where the target environments are on platform 7.4.
If candidates are not upgraded to PegaDevopsFoundation 4.5 and browse artifacts displays the related artifacts, then user can safely ignore this error.
This issue has been fixed in Deployment Manager version 4.6
Note that: Deployment Manager is still backward compatible in terms of functionality, but in diagnostics check on orchestrator repository is failing due to additional checks made on new version. This issue will be fixed if candidates are upgraded to PegaDevopsFoundation 4.5.
What are common issues for Deployment Manager orchestrator cannot connect to a large environment?
Ans: There are a few common issues we have seen come up regularly
There can be possible network issues. Consider an example, when QA is unable to connect to orchestrator then ping or ssh (telnet) with orchestrator host address (along with port number) from the QA environment.
Check whether there is a VPN or firewall that restricts access to the target environment and ensure that the orchestrator is accessible through the load balancer if any. Check this in both directions, from the target environment to the orchestrator and vice versa.
If the environment is on pega cloud contact pega support to get the IP’s of orchestrator & target environments whitelisted for communication.