-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generating feedback from update processes #793
Comments
@akarasulu can you clarify please this issue? |
No not a duplicate. Updates are occasional processes. They're cryptic to us because we do not get enough data when something goes wrong. We should be taking extra precautions. Meaning before doing something performing pre-checks, and logging these results then performing something i.e. deleting or creating a file then doing post-checks to make sure it took effect and logging it. Meaning super duper care to check, log, do action, check, log, for each step. |
Also do not worry about being excessively verbose. This is not like the p2p daemon where it is on and logging all the time. It's ok to over do it. |
My whole point is that a lot of things when they go wrong go wrong during installations and upgrades. Unfortunately we don't handle error checking, logging and exception handling properly in scripts like for Vagrant and for our package post install scripts. We need to get really uber cautious logging and checking before and after every operation to make sure things are as expected and if not log that something is wrong or tell users. Vagrant is also a candidate here since there's a lot of scripts used by it. In general we need to get better at this stuff which we think of doing as an after thought and that's bad practice. |
Post from Slack:
All projects that are associated with building packages and have postinstall scripts should be made to log with extremely high verbosity. They should check before doing some operation for the right conditions before doing it, and report. Then they should do the operation and log the success or failure and error messages. They should then do a check that everything is fine before continuing to the next step. These package postinstall scripts are short lived (they do their thing then die). It's OK to have them be extremely verbose in their logging output so we can capture upgrade problems and fix them. Right now the upgrade process is a black box for us. Let's change this.
The text was updated successfully, but these errors were encountered: