Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1857104 [details] not deployed in application detail Description of the problem: Application deployed via RHACM to non-local cluster has status "not deployed", even when properly deployed and running on managed cluster. In case of deploy to local-cluster, status is shown properly. Release version: * ACM 2.4.1 * OCP 4.8.15 Browser Info: independent Steps to reproduce: Follow instructions at: https://github.com/mheppler-rh/open-cluster-management/tree/main/application-samples/pacman Actual results: Application marked as "not deployed" Expected results: Proper result in RHACM. Additional info:
Created attachment 1857105 [details] deployed only on local cluster
G2Bsync 1024735419 comment KevinFCormier Fri, 28 Jan 2022 23:18:55 UTC G2Bsync Was this an upstream or downstream build? For upstream builds, this may be caused by search not being enabled. Please check if the search UI is functional.
Search UI seems working in my testing env, but customer has issues with search UI - BZ 2042210.
B2Gsync We are not getting search results from the managed cluster. Search does have some data from the managed cluster, but it seems like it stopped updating at some point because neither the Subscription nor the deployed resources are showing up. Application topology cannot compute the status for the remote cluster. Transferring to search squad for investigation.
Kevin, thanks... Is there something I can ask customer to verify the issue has the same root even in customer's env?
B2Gsync If the customer finds the search page is not working at all, they will have the same issue with inaccurate deployment status for applications. If the search page is working but there is no status for a particular cluster, try searching for resources that should be deployed by the application on the managed cluster, for example: cluster:<clusterName> kind:<resourceKind>. If you do not get results but you know the resources have been created on the managed cluster, then a search issue is causing the incorrect deployment status.
The issue mentioned above, BZ 2047273 affects the indexing of data from managed clusters by the search service. If this problem happened in the same ACM instance as BZ 2047273, then that's the root cause. mheppler Please confirm if we can close this issue as a duplicate of BZ 2047273 and continue the discussion there.
Here are two answers from customer - it seems like the same cluster, but not facing issue now: "So the search function usually works in our ACM environment but we have been facing issues with the Overview page and search function from time to time. It seems like this is related to another case we have open related to the very high memory consumption of Redis pod. The more I think about it, the more it seems that these 2 cases could be related as if there is not enough memory to get information from clusters we manage then that would most likely result in the kind of error we are seeing here with this app deployment (unless I'm missing something of course)." and "So have gone into our RHACM environment and I can confirm that the search function is working correctly and I can do searches within all managed clusters. I can also do a search and visualize the application components for pacman app on a deployed cluster so it seems the search is not the culprit then from what I understand. Please let me know if there is anything further we can do to assist in resolving this. We are happy to do a quick working session if required of course." I will verify it...
AAAh... Sorry.. Its the same ACM instance!
The first customer statement in comment 9 correctly summarizes the architecture and the problem. The Application UI uses data from the search service to find the resources deployed in managed clusters, if search is having problems, then the Application UI may show inaccurate data. It's important to mention that the deployment of the application resources by the subscription is an independent process and as a workaround, you can log into the managed cluster to confirm that the application works correctly. I want some clarification on the second statement because it seems to contradict the first one. It's possible that the search service recovered for a brief period before running out of memory.
The root cause is the same as bz 2042210. I'm closing this issue as a duplicate and will continue the discussion about Redisgraph memory and scalability in bz 2042210 *** This bug has been marked as a duplicate of bug 2042210 ***