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] > <javascript:>> 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] <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/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/1e33fc9e-5dba-4802-a9b2-74b5ebadcbbb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
