Hi @namderek,By any chance, when you are installing the new delivery, are you changing the middle tier server or the namespace name? the behavior you explained (IFSADMIN reset and SSO issue) could be related to IAM realm not getting synced after installation. If you use the same Middleware server and same namespace from the values-yaml file, this shouldnt be happening. --/Nishanth
Hi @chanaka-shanil , Thanks for the pointers. With your & Pasindu’s help, we found the root cause and managed to fix it.Issue was: I setup the 23R2 middleware infrastructure using the “Advanced/Manual” mode. Apart from usual commands (eg: ‘KEY’, ‘KUBERENETES’ etc), I had to run the ‘STORAGE’ as well for this environment which I have missed.ps> .\main.ps1 -resource 'STORAGE'https://docs.ifs.com/techdocs/23r2/070_remote_deploy/010_installing_fresh_system/030_preparing_server/50_windows_managementserver/#install_ifs-storage_helm_chartOnce this is executed successfully, I can see a new namespace & 2 pods within it. Then the ifs-storage pod started to work fine. Thanks,/Nishanth
Hi @chanaka-shanil ,I added the IP instead of the host and the result is unfortunately same. I described the pod & the error note is also similar Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedMount 95s (x3 over 10m) kubelet Unable to attach or mount volumes: unmounted volumes=[fss-volume], unattached volumes=[labelinfo secrets fss-volume linkerd-proxy-init-xtables-lock kube-api-access-f6mkl linkerd-identity-end-entity linkerd-identity-token]: timed out waiting for the condition Warning FailedAttachVolume 56s (x12 over 31m) attachdetach-controller AttachVolume.Attach failed for volume "ifs-fss-pv-smb-aspiit-4249944e4445c893f4a70ac42f5f82effb23163d969aa7bdeafe6bc0ad858420" : timed out waiting for external-attacher of smb.csi.k8s.io CSI driver to attach volume ifs-fss-pv-smb-aspiit-4249944e4445c893f4a70ac42f5f82effb2316
Hi @chanaka-shanil ,Thanks for the input. I confirmed the connection from the k8s server to fileshare which is working fine. I couldnt test exactly with the file-share pod though since the pod is not started yet. I tried via another pod (via shell login), the deployment identifies the host/IP successfully. Any other way we could verify this?I will do a reconfig using the IP instead of host and get back to youThanks,/Nishanth
Hi @chanaka-shanil,Below is the last segment of describe which shows the error message. let me know if you need the full describe noteEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedMount 5m7s (x61 over 17h) kubelet Unable to attach or mount volumes: unmounted volumes=[fss-volume], unattached volumes=[kube-api-access-rctjv linkerd-identity-end-entity linkerd-identity-token labelinfo secrets fss-volume linkerd-proxy-init-xtables-lock]: timed out waiting for the condition Warning FailedAttachVolume 17s (x271 over 17h) attachdetach-controller AttachVolume.Attach failed for volume "ifs-fss-pv-smb-aspiit-448281875b94fdf905e063d09a09d46d5303ff0273703ff1e6486d2fc2e984ed" : timed out waiting for external-attacher of smb.csi.k8s.io CSI driver to attach volume ifs-fss-pv-smb-aspiit-448281875b94fdf905e063d09a09d46d5303ff0273
Hello,This is probably due to Timezone or Server time difference between your Management server and Middleware server. This wasnt a major issue before 23R2 but after updating to 23R2, I have noticed the same error.In order to fix this, try to set the same time on both the servers and regenerate the kube config (.\main.ps1 -resource 'GETKUBECONFIG')Hope this helps!/Nishanth
Hi,Stopping DB deployment is not recommended but instead when the execution is taking more time than the usual, you can check the blocking sessions on the database. You can use PLSQL to check the blocking sessions caused by other DB jobs and if you can validate that they can be killed at that moment, you can safety kill them to give priority to your installer session. Be cautious, your installer session & other important DB jobs will be listed there as well so do not kill them. Also, if you want to run only the middle tier, you can use “--set action=mtinstaller” in the installer.cmdhttps://docs.ifs.com/techdocs/22r2/070_remote_deploy/010_installing_fresh_system/200_installing_ifs_cloud/035_ifs_cloud_ifsinstaller/020_installer_actions/Regards,Nishanth
Hi,You can try the grants explained in the previous comments. However, the root cause could be that Oracle 19.16 is not compatible with UPD11. If you try a Oracle version which was released before UPD 11, this error or any other related errors can be mitigatedRegards,Nishanth
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.