Paterson, Duncan
2017-07-18 10:05:13 UTC
Dear all,
as a spin-off from this stack-overflow thread: https://stackoverflow.com/questions/45127152/how-to-abort-and-cleanup-app-installation-on-exist-instance-that-dont-meet-the on how to go about the following problem.
Exist's default memory configuration is quite conservative. Yet, when trying to install a package on a clearly underpowered instance, exist doesnât fail very gracefully. It continues the install routine until it either runs out of disk-space, or memory and consequently freezes and crashes. At best there is an unspecific error, reported in the package-manager and the users are left to clean up the mess.
My own attempts to deal with this are in the stack-overflow thread. I can either throw an error during pre-install which will prevent the instance from crashing and inform the user, but this wonât clean up after itself. Since pre-install execution is halted and I have no resource to call repo:undeploy and repo:remove from. So users have to manually cleanup the improperly installed app (which is registered to package-manger and dashboard despite the abort of pre-install.xql). Alternatively, I can util:log() an error and immediately clean-up, but this is not transparent to the user without checking the logs. They simply get thrown back to the dashboard as it was before they selected the .xar for the install.
I think there are 3 values that should be available to repo.xml that could make this more robust: min-memory, min-cache, min-storage. If a dev has declared any of them the install routine should perform a simple check during pre-install and throw an helpful error message, that the instances fails to meet the specs. Ideally, the user would also get the chance to perform the cleanup of the failed install right then, e.g. as a pop-up in package-manager.
I m happy to have a go at the package-manager code but I would need help with making the required changes to understanding repo.xml
But before i embark on this my question to the community: bad idea, good idea, anything i m overlooking here.
Greetings
Duncan
as a spin-off from this stack-overflow thread: https://stackoverflow.com/questions/45127152/how-to-abort-and-cleanup-app-installation-on-exist-instance-that-dont-meet-the on how to go about the following problem.
Exist's default memory configuration is quite conservative. Yet, when trying to install a package on a clearly underpowered instance, exist doesnât fail very gracefully. It continues the install routine until it either runs out of disk-space, or memory and consequently freezes and crashes. At best there is an unspecific error, reported in the package-manager and the users are left to clean up the mess.
My own attempts to deal with this are in the stack-overflow thread. I can either throw an error during pre-install which will prevent the instance from crashing and inform the user, but this wonât clean up after itself. Since pre-install execution is halted and I have no resource to call repo:undeploy and repo:remove from. So users have to manually cleanup the improperly installed app (which is registered to package-manger and dashboard despite the abort of pre-install.xql). Alternatively, I can util:log() an error and immediately clean-up, but this is not transparent to the user without checking the logs. They simply get thrown back to the dashboard as it was before they selected the .xar for the install.
I think there are 3 values that should be available to repo.xml that could make this more robust: min-memory, min-cache, min-storage. If a dev has declared any of them the install routine should perform a simple check during pre-install and throw an helpful error message, that the instances fails to meet the specs. Ideally, the user would also get the chance to perform the cleanup of the failed install right then, e.g. as a pop-up in package-manager.
I m happy to have a go at the package-manager code but I would need help with making the required changes to understanding repo.xml
But before i embark on this my question to the community: bad idea, good idea, anything i m overlooking here.
Greetings
Duncan