We will not be doing this, by the way.
On Mon, Jun 23, 2014 at 5:02 AM, Marc Trudel <[email protected]> wrote: > Maybe something like: > > - name: "Some task" > errorMessage: "This task might have failed because of bad network > connectivity" > curl: [...] > > Or something like that. > > I have no idea what format would be nice. But I am thinking that it could > be nice to list at least some of the potential cause of the error which are > known at the time of writing the role or playbook. > > On Monday, June 23, 2014 1:03:40 AM UTC+9, Michael DeHaan wrote: > >> I'm not sure how this relates to Ansible specifically. >> >> If you can phrase this in terms of improving Ansible error messages in >> ways that would make better sense for non-technical users, I'm interested >> in the discussion. >> >> >> >> >> >> On Sat, Jun 21, 2014 at 1:18 PM, 'Petros Moisiadis' via Ansible Project < >> [email protected]> wrote: >> >>> 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]. >>> 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/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 >>> <https://groups.google.com/d/msgid/ansible-project/53A5BE4C.4070403%40yahoo.gr?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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/102575d5-eb65-480f-b3c7-bfe3b14f3fe5%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/102575d5-eb65-480f-b3c7-bfe3b14f3fe5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CA%2BnsWgzvtJWFcagYyptOae41XW5LO9G%2B5MQF1ukHw9O%3Ddj%3DM6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
