I tried doing a deployment overnight. The solution consists of 8 files. The first 4 were “built” successfully (does a build simply consist of creating a clone?), but the 5th one failed.
I’ve run this deployment (with the same set of 8 files) successfully once before.
Is there some way I can find out what went wrong, so I can figure out how to prevent it from happening again?
Here’s the “detailed log” from the portal:
Phase |
File |
Message |
Duration |
scheduled |
- |
deployment scheduled |
00:00.000 |
queued |
- |
Deployment queued |
00:00.000 |
starting |
- |
Starting deployment: Deploy to PROD |
00:00.000 |
starting |
- |
8 files |
00:00.008 |
closing |
- |
Starting to close files |
00:02.007 |
closing |
- |
Files closed successfully |
00:18.208 |
building |
- |
Sending just in time build request to source server |
00:18.217 |
building |
- |
Just in time build started on source server |
00:19.207 |
building |
- |
Build running, completed 1 of 8 files |
00:56.380 |
building |
- |
Build running, completed 2 of 8 files |
01:04.560 |
building |
- |
Build running, completed 3 of 8 files |
01:20.925 |
building |
- |
Build running, completed 4 of 8 files |
02:10.071 |
building |
- |
Build server is unreachable: HTTP error: 502 - Bad Gateway: undefined |
02:27.966 |
opening |
- |
Starting to open files |
02:29.493 |
opening |
- |
Files opened successfully |
02:39.558 |
post-deployment script |
- |
Post-deployment script not run since deployment failed |
02:39.566 |
done |
- |
Deployment process failed. Original files are unmodified. |
02:39.573 |
post-deployment steps |
- |
Deleting schedule |
02:39.612 |
Hi Mislav,
What operating system are you using? Is it Windows?
Thanks
Todd
Yes, Windows. Sorry, should have mentioned that previously.
Windows Server 2022 Datacenter
FMS Version: 20.3.2
OttoFMS Version: 4.2.3.240313464
Hi Mislav,
Thanks for confirming that. I suspected as much.
Could you send us the otto-info.logs from both servers? You can use a direct message or email to support@proofgeist.com if you want.
Thanks
Todd
Hey,
I just noticed that you are on a slightly older version of OttoFMS. The current version has a fix in it that should make this problem go away.
Read this for more info for updating
Thanks, I’ll update and try to deploy again.
Do you still want the otto-info.logs from both servers?
No.
Upgrade your servers, and try it again.
Let us know what happens
Todd
I got a different kind of error this time: Deployment crashed.
Here’s the detailed log from the Otto portal:
Phase |
File |
Message |
Duration |
scheduled |
- |
deployment scheduled |
00:00.000 |
queued |
- |
Deployment queued |
00:00.000 |
starting |
- |
Starting deployment: Amps Deploy to PROD |
00:00.000 |
starting |
- |
8 files |
00:00.008 |
unknown phase |
- |
Deployment crashed |
00:05.041 |
Versions from both DEV and PROD:
FMS Version: 20.3.2
OttoFMS Version: 4.3.3.240429424
I’ll DM you the Otto logs from both servers.
What are the server stats? How many CPU’s and how much RAM?
Todd
Mislav,
It looks like the deployment was triggered twice in a row. That shouldn’t have caused an issue. It should have just ignored the second attempt. But instead it just aborted the deployment. We’ll look into that.
It’s possible that a double click got sent through. We’ll also look at that.
But in the meantime, you may want to just try again.
Thanks
Todd
Thanks Todd. I’ll give it another try tonight and will report back how it goes.
Server specs:
PROD: m6i.2xlarge … 8 vCPUs, 32 GB
DEV: t3.large … 2 vCPUs, 8 GB
Last night’s deployment worked without any problems. Thanks for the support you’ve provided to get me there.
In the previous two attempts, the glitch happened early on, before DMT. I was talking to a colleague of mine, and he reported a similar experience. In his case, he kicks off the deployment ad hoc and is able to monitor it during the initial phase, so it’s no big deal for him to manually retry it.
In my case, I have to schedule my deployment for overnight, because of the work hours that my client maintains, so it’s not convenient for me to retry it manually. Something to consider for you guys is to build in some retry logic if the deployment fails in those initial steps.
Thanks again for making this great tool available to the community.
1 Like
Hi Mislav,
If your colleague could send us the logs from deployment server when that happens, that would be helpful. The more information we can get the better.
Thanks
Todd
Hi Todd,
I’ve sent the logs from my server to the support email.
Thanks!
-Emilio
1 Like