We cannot obviously have a meaningful message for all errors, but I think it would be nice to offer something in the ballpark of "you might want to check the following things on your system". For my use case, I think that would be a start.
On Monday, June 23, 2014 11:14:31 PM UTC+9, Michael DeHaan wrote: > > I don't think it's a very effective idea for Ansible, when there are often > thousands of things that could produce a failure. We will share the > failure message, but the "why" is something that humans should decipher. > > > > > On Mon, Jun 23, 2014 at 9:45 AM, Marc Trudel <[email protected] > <javascript:>> wrote: > >> Hum, what do you mean? That it is a bad format, a bad idea overall, or >> that it will need to come from the open-source community? >> >> Ad for the format, I don't really care. I can try to think of something >> better. >> >> >> On Monday, June 23, 2014 9:12:07 PM UTC+9, Michael DeHaan wrote: >> >>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/1e33fc9e-5dba-4802-a9b2-74b5ebadcbbb%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/1e33fc9e-5dba-4802-a9b2-74b5ebadcbbb%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/9eefb025-6d2e-4a52-ac9a-4e36b4cb8c8d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
