Otto FMS reports file was successfully opened when it is not

After performing a deployment with OttoFMS v 4.0.6 the deployment is reported as successful and the opening is shown as successful. The file is not re-opened on the server. Looking at the detailed log shows that the file opening failed as no encryption key was provided.

I believe the deployment should not be marked as successful, and in the summary should not show opening as successful if opening the file failed to open due to incorrect or missing encryption key.

Hi Gabe

Thanks for reporting this, There does seem to be an issue with what is getting reported.

Was the file operation for this file an “Install”, “Replace”, or “Migrate”. I am going to guess it was not Migrate, but I’d like to confirm that.

There are some downstream effects of calling a deployment “failed”. For example it will revert all the changes made in the Deployment.

So would you want a file not opening becuase you forgot to an encryption key on the install to cause all the changes made to all the other files in that sub-deployment to be undone? Or would you rather just go open the file?

Thanks for helping us figure this out

Todd

The operation was a ‘Replace’.

My option would be that it should fail and sub-deployments should fail if the file doesn’t re-open for whatever reason. If the user has missed some required information from the deployment then I guess it should go back to the pre-deployment status. The user can then go and see what went wrong and make what ever changes are required and retry the deployment.

Thanks Gabe

We’ll dig into this.

Todd

I disagree.
So when the server restarts but no files open then is not a failure as I have asked it to not automatically open files… It is at best a partial success

A failure should be that something in the migration failed, not that at the end the (new) file did not open. A best it is incomplete, rather than failed - and in that case I want to be notified but I really don’t want things rolled back.

If a file user password is wrong then by all means count this as a failure as the DMT will not carry out its job.

Again, if the job is a deploy all I want to know the file arrived in the desired location, it might be that I need to go into admin console on new server and enter and save encryption key

I think that is what we were thinking but, I cna see Gabe’s point.

Todd

Yeah, I can see it both ways. The migration was successful, but the post processing such as reopening the files failed.

I think if I was making a copy of live data back to a testing/staging file, the migrating the latest release from a dev server into the testing/staging I would want everything to be back where its was before I started.

I think that’s the atomic or transactional way I might want it to behave. Everything happened or nothing happened.

I’m sure there are lots of circumstance were people might want different things to happen.

Thanks @toddgeist for the very speedy reply. It does look like a great a great improvement on Otto v3. The ability to do sub-deployments is something I’ve needed for a while and is going to allow for our company to much better automate releases.

There is definitely an issue with how the report came out. We will fix that.

Todd

I would chime in if I may:
I’d really think this should be configurable. If I watch the migration and see that the file has not opened I can do it myself esily.

If I go to sleep (because it might take hours on a long migration) or do a scheduled migration I might not want to leave a server in an undefined state (some files open, others not).

1 Like

Do y’all think this could be helped with something like a “Revert deployment if files fail to open” option on the deployment? That way you could do some configuration on whether the deployment should revert to the starting state when it fails in this way.

Tobias’ point about wanting different behavior based on whether you are watching the deployment or not makes a lot of sense to me.

-Kyle

+1
and anotherr 18 characters

1 Like

Yeah, having it as a setting would be good. I suppose the question is what should the default behaviour should be?

I think the file not opening because I didn’t set the encryption key is the sort of thing I might do once before realising the mistake. I think re-opening the file but show an error should be if you turn the setting on. If you are choosing this then you have decided to enable this behaviour.