service-account doesn't get synced when following Event Management procedure on https://github.com/IBM/cp4waiops-gitops/blob/main/docs/how-to-deploy-cp4waiops-33.md

[ks-ibm]

Hi!

As per title:

Gives in diff yaml:

Following up with the team tomorrow morning.

Thanks!
K

[gyliu513]

anything wrong with ignorefield?

[morningspace]

First of all, I'd say this out-of-sync issue will not impact the install process. It is just the "noise" that makes people confusing. Of course, we need to fix it, either by code or docs.

Secondly, it should have been fixed by the Argo CD ignoreDifferences settings here. However, the reason that it does not work is because @ks-ibm is not using this Argo CD app stored in git repo in the all-in-one helm chart, but instead, to install event-manager by directly creating an Argo CD app on the fly. If we look at the Argo CD app on that env, there is no such ignoreDifferences there.

This gives us a nice indicator that ultimately I think we need the additional Argo CD app to customize the Argo CD default behavior, which has already been implemented in the all-in-one helm chart here, because we can add the ignoreDifferences centrally like this, which will solve the above problem, as it does not rely on adding such ignoreDifferences in each Argo CD app, no matter it's pre-stored in git repo or created by user on the fly. We can add that to our docs as prereq instructions. @liyanwei93

[liyanwei93]

@ks-ibm In the case of a successful installation, this resource will automatically sync successfully. The reason for this resource sync fail is that the sync process has been blocked on other resources.

BTW @morningspace

This gives us a nice indicator that ultimately I think we need the additional Argo CD app to customize the Argo CD default behavior, which has already been implemented in the all-in-one helm chart here, because we can add the ignoreDifferences centrally like this, which will solve the above problem, as it does not rely on adding such ignoreDifferences in each Argo CD app, no matter it's pre-stored in git repo or created by user on the fly. We can add that to our docs as prereq instructions.

You mean we can add a section that users can manually deploy the argocd kind before installation as Prerequisites in the doc?

[ks-ibm]

You mean we can add a section that users can manually deploy the argocd kind before installation as Prerequisites in the doc?

I did follow the ArgoCD requirement in the doc, but that was an "default" deployment without that ignorefield thingy which is included in the all-in-one (which I didn't pick).

I'll hang in here until the offical GA, and see if my ArgoCD is friendly enough to continu. I'll update this case accordingly.

Thanks @liyanwei93 & @morningspace ! Appreciate the support !
K.

[morningspace]

@liyanwei93

You mean we can add a section that users can manually deploy the argocd kind before installation as Prerequisites in the doc?

What I mean is to allow users to create the Argo CD app argocd-custom that points to config/argocd/openshift or config/argocd/kubernetes (depends on where the Argo CD instance is deployed), before create the Argo CD app for CP4WAIOps.

In all-in-one helm chart, this is done automatically because the argocd-custom app is a sub-app of the all-in-one app at root level. When we create the all-in-one app, Argo CD will help us create the sub-apps automatically. If users are not using all-in-one app, such as the above case, we will tell user to create the argocd-custom app manually. With that, there will be two steps to launch an CP4WAIOps instance. First, create argocd-custom app, second, create the app for AI Manager, or app for Event Manager, or both.

[ks-ibm]

Good news! After GA, the ArgoCD deployment continued and this issue with unsynced service-account got straightened out. Ran into another pitfall, but that's for another story!

I think this may be closed now?

[gyliu513]

Good, let me close this one, thanks @ks-ibm

[gyliu513]

@morningspace @liyanwei93 Can we create the SA procedurally, as a resource, Argo will keep deleting the other secret attached to the account by the operator.

[nastacio]

@gyliu513 I don't think that SA can be managed through Argo. Note that the operator (or maybe it is OCP) will try and add more secrets to the SA and Argo will delete those on the next synchronization, which will break the SA.

The operator and Argo will keep "fighting" each other, adding and removing the secret from the SA.