G2Bsync 852332981 comment fxiang1 Tue, 01 Jun 2021 17:59:15 UTC G2Bsync I took a look at the customer's application and it seems that they are embedding the placementrule inside of the subscription YAML. Currently the Application UI does not support embedding the placemenrule inside the subscription YAML and that's why the customer is seeing the behavior where the node statuses are not showing up properly. Is it possible for the customer to move the embedded placementrule to a separate placementrule YAML? I think this should resolve the issue.
Customer has a question: As we identified the problem now, please advise what will be the process and timelines for adding visualisation functionality of inline placement rule definitions: === subscription.yaml === apiVersion: apps.open-cluster-management.io/v1 kind: Subscription ... spec: ... placement: clusterSelector: matchLabels: zone: dev Please, is there some plan to support for inline rule definition?
I have tagged Offering Management as to the request. Our current product direction is to always go through placementRule, even for subscriptions targeting the hub. This is why in the Wizard for Create Applications, when you target the local-cluster, it uses a placementRule with "metadata.labels.local-cluster: true". The subscriptions.apps.open-cluster-management.io/Spec.Placement.Local: true is intended only for single cluster use in the Community and for the propagated subscriptions on the ManagedClusters. If you look at your subscriptions that are propagated to the ManagedCluster (oc get appsub -A), you will see that they are all set with Placement.Local: true. This is the implementation our Applicaiton Console is geared toward.
Hello, customer is facing the same issue again: > I'm facing same problem again. This time subscription uses PlacementRule. I've also attached screenshots, which depict: > > * resources target correct cluster > * resources were deployed and instantiated on the target cluster > * UI doesn't report resource status > > Please advise if you need anything else. > > File definitions: > > --- > apiVersion: apps.open-cluster-management.io/v1 > kind: Subscription > metadata: > name: nginx-demo-alpha > labels: > acm-app: nginx-demo > spec: > channel: monitoring-ch-helm/channel > name: bitnami-nginx > packageFilter: > version: "0.1.0" > placement: > placementRef: > name: alpha > --- > apiVersion: apps.open-cluster-management.io/v1 > kind: PlacementRule > metadata: > name: alpha > spec: > clusterSelector: > matchLabels: > tier: alpha > --- > apiVersion: app.k8s.io/v1beta1 > kind: Application > metadata: > name: nginx-demo > labels: > acm-app: nginx-demo > spec: > selector: > matchLabels: > acm-app: nginx-demo Screenshots are in screenshots2.tar.gz
Created attachment 1789225 [details] Set of screenshots 2
G2Bsync 856026787 comment fxiang1 Mon, 07 Jun 2021 15:20:28 UTC G2Bsync It looks like the customer is having issues with a different application now. Hopefully the previous application is working now with the separate placementrule suggestion. For the `bitnami-nginx` application, the package name and alias is missing from the subscription which is causing the issue. I would suggest adding those to see if that resolves the issue: ``` apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx-demo-alpha labels: acm-app: nginx-demo spec: channel: monitoring-ch-helm/channel name: bitnami-nginx packageFilter: version: "0.1.0" placement: placementRef: name: alpha packageOverrides: - packageName: bitnami-nginx packageAlias: bitnami-nginx ``` This is the same as to what they are already doing in the previous application: https://github.com/vladimir-babichev/gitops-operating-platform/blob/main/zones/alpha-westeu-3/kubernetes-external-secrets.yaml This is also mentioned in our documentation in order for the topology to work properly: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html/manage_applications/managing-applications#resource-topology