However, deployment fails with the error message that ImageId is not set. Digging further, it looks like that there seem to be no public OpenViduServerCE-AMIs starting with version 2.21.0 anymore. Therefore, the Lambda function which should copy the corresponding AMI to our AWS account fails and the error described above occurs.
Our initial deployment was mid of May 2022 and it looks like that at this point of time, AMI for the version 2.22.0 existed. At least, I found a copy of the AMI having a name which was generated by the Lambda function.
Was there a change in the installation procedure since May of this year which we overlooked? Or something other important change? Or are the AMIs really just missing and will appear soon again?
Yes, the installation process is different to allow users to have AMIs in their account and not depend on our official ones and be in more control of the deployment.
What is the error you have in your Lambda?. It is not attached.
It could be that the account you are using to deploy has not the proper policy to be able to create a Lambda or to copy AMIs. You need to give permissions to the account.
If you provide more feedback about your error, I will be glad to help.
Most important finding first: we tried to redeploy the same version of OpenVidu in a new CloudFormation stack and it worked without issues, i.e., the problem is somewhere on our side. I, therefore, can close this issue.
But nevertheless, here some more information what we did before - maybe some other people are thinking to do the same as we did, and will plan a little bit better as we did.
We used Terraform script which deploys CloudFormation stack on AWS. This worked quite well and OpenVidu was installed as expected. However, after some months, we updated some resources and wanted to reapply our Terraform scripts. But it seemed that Terraform was no able to read the OpenVidu secret and tried to update the OpenVidu installation. And this did not work, as the error message in the log of CloudFormation shows:
Unfortunately, I do not have any other logs. For some reason, Lambda function does not produce any (I assume it is missing the rights to write to CloudWatch). However, I can confirm that it has permissions to copy and describe images.
I now strongly assume that the main issue was that Terraform tried to update the stack. For some not understandble reasons, we used “latest” stack such that Terraform tried to upgrade OpenVidu 2.22 to OpenVidu 2.24.
And as it is stated in the deployment upgrade documenation, it is strongly advised to not upgrade across multiple major version… so probably something went wrong during this first upgrade and from that point on, everything was broken. Finally, our solution was to tell Terraform to ignore changes of the OpenVidu secret such that Terraform does not try to update the stack once again. Not what we wanted to have, but it works for us.
I really like this post where the resolution of the initial problem is so well explained
Yes, the best way to upgrade is to deploy a new Cloudformation.
It’s normal that by following Terraform guidance, the most intuitive thing to do is to “Update” the stack (which is an actual option of Cloudformation), but we recommend in the documentation to deploy the stack again because it is the best option to ensure that the environment is not degraded, outdated or some new features are missing.
such that Terraform tried to upgrade OpenVidu 2.22 to OpenVidu 2.24.