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).
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
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.
