Failed to deploy using OpenLiberty Operator 0.8.1

[zhengchang907]

Bug Report

What did you do?

1. I created an AKS cluster
2. I installed the OpenLiberty Operator 0.8.1 using kustomize
3. I tried to deploy my sample app (without db) but failed
4. I verified it still work with version 0.8.0

I was following this guide, just using 0.8.1 instead of 0.8.0

What did you expect to see?

Able to deploy successfully

What did you see instead?

$ kubectl get openlibertyapplication javaee-cafe-cluster
NAME                  IMAGE                                         EXPOSED   RECONCILED   AGE
javaee-cafe-cluster   zchang0408acr.azurecr.io/javaee-cafe:1.0.25             False        5s

$ kubectl describe openlibertyapplication javaee-cafe-cluster
<----trimmed---->
Status:
  Conditions:
    Last Transition Time:  2022-04-08T09:03:46Z
    Message:               Service account javaee-cafe-cluster isn't ready
    Status:                False
    Type:                  Reconciled
  Image Reference:         zchang0408acr.azurecr.io/javaee-cafe:1.0.25
Events:
  Type     Reason           Age                      From                   Message
  ----     ------           ----                     ----                   -------
  Warning  ProcessingError  <invalid> (x9 over 22s)  open-liberty-operator  Service account javaee-cafe-cluster isn't ready

Environment

OpenLiberty Operator 0.8.1

Possible solution

Additional context

[zhengchang907]

Tried to install 0.8.1 using kubectl but also failed in app deployment step, later tried with 0.8.0 and it worked as expected

[leochr]

@zhengchang907 To resolve some timing issues with pulling the image from the internal image registry, we added a check (included with 0.8.1) to ensure that the ServiceAccount includes an image pull secret. In OpenShift, the ServiceAccount automatically gets an image pull secret. In your environment, it seems that the ServiceAccount doesn't have a secret. Please confirm if that's the case. Is that expected? If so, wondering how the images are pulled from the internal registry, assuming there is one. Thanks.

[zhengchang907]

Hi @leochr

Yes. In my case, I attached the Azure Container Registry to AKS cluster so there is no need for pull secret, and it is expected.

Here is the doc: Authenticate with Azure Container Registry from Azure Kubernetes Service

The command I used to do so is:

az aks update -n $CLUSTER_NAME -g $RESOURCE_GROUP_NAME --attach-acr $REGISTRY_NAME

[leochr]

@zhengchang907 Thank you. We'll need to fix the service account validation logic to account for this. It'll be released under 0.8.2. Let you know when it's available. It'll take at least 2 weeks to complete the release cycle

[zhengchang907]

@leochr Thank you, looking forward to it

[bconey]

Just wanted to add that this same behavior was seen when using the 0.8.1 operator on an EKS cluster using a private registry. The secret for the registry was created in the namespace where the application was to be deployed, but the same errors as noted above for the service account were logged. After adding the secret to the service account, the deployment completed successfully.

[dfateyev]

Please consider to release the updated version with the fix. The current issue blocks using the operator in all Kubernetes clusters / providers where are no pull secrets provided automatically.

[leochr]

We expect to have the release by the end of this month

[dfateyev]

@leochr is there any news on the release with the fix? Thanks!

[leochr]

@dfateyev Unfortunately, we had a setback. But we are working on it. I'll get back to you on the expected release date by the end of this week.

[zhengchang907]

Hi @leochr, any updates on the release? Thanks

[majguo]

Hello @leochr I'm teammate of @zhengchang907 , I noticed that 0.8.2 is released and also verified that the issue @zhengchang907 reported has been fixed in 0.8.2. Thanks for the fixing.

[leochr]

I was about to update this issue regarding the 0.8.2 release. Thanks for the confirmation @majguo