Bug 1951384

Summary: Applications won't create properly on native K8S cluster
Product: Red Hat Advanced Cluster Management for Kubernetes Reporter: Fran Kemp <francis.kemp>
Component: App LifecycleAssignee: Xiangjing Li <xiangli>
Status: CLOSED ERRATA QA Contact: Eveline Cai <ecai>
Severity: high Docs Contact: bswope <bswope>
Priority: unspecified    
Version: rhacm-2.2.zCC: xiangli
Target Milestone: ---Flags: ming: rhacm-2.2.z+
ming: needinfo+
Target Release: rhacm-2.2.3   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-04 20:14:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fran Kemp 2021-04-20 03:25:09 UTC
Description of problem:

Running RHACM in the IBM Cloud
Have successfully imported 1 OpenShift cluster, 1 native K8S cluster and 1 minikube cluster.  So we are managing 4 clusters, including the local one.

Trying to distribute a small mariadb application to all 4 clusters.  It works fine on the OCP clusters, but will not spin the pods up on the non-OCP clusters.

Here is what I get on an OCP cluster:

$ oc get all -n mariadb
NAME                   READY   STATUS      RESTARTS   AGE
pod/mariadb-1-deploy   0/1     Completed   0          46m
pod/mariadb-1-vrmqc    1/1     Running     0          46m
pod/mariadb-1-z2cks    1/1     Running     0          46m

NAME                              DESIRED   CURRENT   READY   AGE
replicationcontroller/mariadb-1   2         2         2       46m

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/mariadb   ClusterIP   172.21.237.26   <none>        3306/TCP   46m

NAME                                         REVISION   DESIRED   CURRENT   TRIGGERED BY
deploymentconfig.apps.openshift.io/mariadb   1          2         2         config

And here is the result on K8s and minikube:

$ kubectl get all -n mariadb
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/mariadb   ClusterIP   10.107.147.194   <none>        3306/TCP   12m

The OCP clusters are downloading the mariadb pods from quay.io/bitnami/mariadb:10.3 and the non-OCP clusters are not able to do that.

I'm able to pull the mariadb image manually on the non-OCP clusters using podman pull:

$ podman images
REPOSITORY               TAG     IMAGE ID      CREATED       SIZE
quay.io/bitnami/mariadb  10.3    79113d63dc86  32 hours ago  324 MB

Even when I pull the image manually, the application won't start on the non-OCP clusters.

I had to modify the MultiClusterHub resource to get the non-OCP clusters to be managed - is there a similar setting for the applications?

Version-Release number of selected component (if applicable):
2.2

Comment 1 Mike Ng 2021-04-20 16:51:36 UTC
G2Bsync 823365288 comment 
 xiangjingli Tue, 20 Apr 2021 15:25:16 UTC 
 G2Bsync

The mariadb app has a openshift specific resource - `deploymentconfig.apps.openshift.io/mariadb` . This is not supported in native k8s cluster. that caused the app deployment success on OCP but failure  on native ks8 cluster.

This is not a ACM app lifecycle issue. To workaround this, need to wrap the application using the generic `deployment` KIND instead of OCP specific `deploymentconfig` KIND resource

Comment 2 Fran Kemp 2021-04-21 04:01:49 UTC
Thanks! - didn't notice that.   I feel dumb now  :)

Just to confirm - there is no issue deploying applications from RHACM to a native K8S cluster as long as it is coded correctly.  Correct?

Comment 3 Mike Ng 2021-04-21 19:43:24 UTC
G2Bsync 824127299 comment 
 xiangjingli Wed, 21 Apr 2021 14:55:12 UTC 
 G2Bsync

Yes, please make sure all the resource KINDs  involved in the application should have their relative CRDs pre-deployed in the managed k8s cluster.  

If no, you can create another ACM subscription (subscriptions.apps.open-cluster-management.io ) to deploy the CRDs ahead of the real application resources deployment.

Comment 4 Fran Kemp 2021-04-21 21:10:48 UTC
Thanks - will do.

Comment 10 errata-xmlrpc 2021-05-04 20:14:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat Advanced Cluster Management 2.2.3 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1499