Hi @ORFJAN,
It’s probably best to delete the destination MT using set action=delete and then do the deployment of the MT after. This was the approach that we use in our cloning scenario and didn’t face a similar issue to what you are seeing.
Cheers
Hi Sajith,
yes, we were investigating issue and we already applied this
.\installer.cmd --set action=delete --values c:\ifsocdev\ifsroot\config\ifscloud-values.yaml
.\installer.cmd --set action=mtinstaller --values c:\ifsocdev\ifsroot\config\ifscloud-values.yaml
unf. it did not help.
Jan
Hi @ORFJAN ,
That is interesting. Have you raised this with support? The last time i’ve done the cloning activity was when i was running 21.1 so wondering whether this is something new that happens after 21r2. Quite keen to figure that out my self.
Cheers.
Hi @ORFJAN ,
Just noticed that your iam pod ise in “crashloopBack” Did you check which container this is given that iam pod has 2? what sort of error does the describe command give you? may be the schema is not getting updated because is ifsapp-iam is failing before it gets a chance to re-initialize.
Cheers
Hi @Sajith D ,
last time we did the DB clone with 21R1 too and it was working well, however I was claiming that IAM configurations we did in the application manually was lost and we had to re-create some IAM clients.
I’m sharing dump of the server, it seems IAM pod can connect DB (I can see that from DB sessions) but can not execute some action in DB.
Jan
Hi @Sajith D , we found there is dead process which was alerting in logfile, we removed that and restarted the DB, this fixed the issue.
However I have to say the IAM configurations we did in TEST are lost again.
Thanks for checking from your end!
Jan
I have a similar problem as above except that I was installing a new test environment based on ifs_cloud_values from the prod environment. The database reference in the file has changed. IFS Cloud has installed. You can log in to the database, but I have a similar problem with ifs_iam_client (as in the screenshot). In PL/SQL, I don't see a session regarding IFS_IAM. Passwords are similar.
Steps taken:
1) restart the PODs
2) delete PODs
3) reconfiguration
Can you give any hint?
in addition, there is probably a problem with passwords in the MT logs, but where?
Problem solved. It turned out that there was no physical space on the Oracle server. The messages in this case on MT were very confusing….