On 06/21/2014 06:59 PM, Marc Trudel wrote: > Greetings, > > Someone at work brought this one to me, and I thought I would put the > question out there and see what others do/think about this. > > We have a deployment tool which early on transformed itself into a > local development environment management tool as well (it provisions a > VM according to the configuration and requirements of a project, which > can me modified at any time using a configuration file). Works > fantastically well, but unlike system managers, developers don't want > to care about error cases. So for required configuration, we go check > the data wherever a default is not possible, and print out a > human-readable error with some details. However, it happens sometime > that the failure is due to a bug in the playbook, or to some manual > modifications a user has done on his machine, and so on. > > My question would be: is there a proper pattern to print out > human-readable errors which would be oriented to a customer and not to > someone doing deployments and operation for a living? I am thinking of > pushing the tool itself towards less and less technical people (for > all sorts of reasons), so for me it would be nice if we had a way to, > say "This error should never happen, contact operations" or "This my > be caused by a network connectivity problem. Check your internet > connection, and please try again" when you try to download something > and it fails. I can imagine that the ability to create generic error > messages would also come handy. > > Cheers! > -- > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/1b315310-0be0-48d8-8a00-117815a33ecc%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/1b315310-0be0-48d8-8a00-117815a33ecc%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout.
Hi, There is no single pattern for system failure causes. Systems can fail in many ways by many causes. However, you can follow a statistical method by analyzing the most common errors caused by user configuration or usage and create a mapping with possible remedies or workarounds. Make sure though that you do not overestimate your guessing for an error cause and do not hide any useful details. You may have historical indications that an error was caused by user misconfiguration when it could be actually a bug. So, I would suggest to always have your tool create a detailed error report for your system engineers, regardless the error. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53A5BE4C.4070403%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
