Closed keunlee closed 9 months ago
+1 Exact same issue on OCP 4.5 / OKD 4.5
We had this issue. Checking permissions on mount path /opt/system/public/system, we found out that group was wrong and did not have write permissions. Deleting de PV bounded to system-storage PVC and using a new one solved this and mount path now has write permissions and group is 1000.
We had some issues with the storage service on the days before this, so we think it had something to do with that.
+1 Exact same issue on OCP 4.10
I am afraid we cannot do much to help you about this. This isssue is highly coupled with the RWX storage provided by the OCP deployment. In our testing env RWX works fine with the DeploymentConfigs created by the operator.
The only thing I can think of is to "play" with the pod's security context to configure volume permission and ownership change policy until you find some configuration that works for your specific environment. The pod's security context can be customized in the system-app
DeploymentConfig, at the podTemplate spec (.spec.template.spec.securityContext
). The operator will allow you to set a custom value for the security context directly in the DC (it will not revert back changes added).
If you succeed, let us know so we can add it to the documentation for future reference.
Closing as no response since May 2022
Environment:
Cluster Nodes Info:
Issue Description:
After successful installation of the 3scale operator from the OperatorHub, creating an instance of APIManager is unsuccessful, resulting in a deploy prehook repeated failing, preventing the APIManager instance from completely and successfully deploying.
The APIManager configuration used:
SC, PV, PVCs:
Failed Pods and Pods that are in init:
The
system-app-1-hook-pre
pod logs the following message: