My hope was not for more of a standard "ansible way", but here are the available options those of us who have only worked with YML because of ansible. Until this post, I did not know that some of the options existed. With the number of contributors to the project, I hope I am not alone in being newer to YML. Another benefit of this is we know what formats are supported by ansible. It took me a lot of guesswork and research to discover I could put them on multiple lines in the first place. It took me another 2 years to now realize I don't have to use apt: >.
On Thu, Aug 28, 2014 at 9:45 AM, Jeff Geerling <[email protected]> wrote: > At this point (and likely for some time, maybe forever?) there is no > formal specification/best practices listing for Ansible, and that's both a > blessing and a curse. It's nice to say "this way is the best", but it also > means that there's less freedom to use a style that fits your needs. > > I'll be writing up a blog post soon (and adding the info to Ansible for > DevOps in a Best Practices appendix) summarizing these different styles, > and showing why I use the one I use—but also mentioning why it is probably > not for everyone. > > I think the discussion in this thread's been incredibly helpful, and I'm > glad Michael gave some of his reasons for preferring the params-on-one-line > approach. I think it also has to do with how much time an individual spends > more on the 'dev' side or the 'ops' side of the devops equation—it seems to > me people with more of an ops/get-it-done approach favor terseness, while > people more on the dev/purist side prefer rigid syntax, multiline for > VCS/diff ease, and structure rather than freedom. (All generalizations, I > know... but that's my experience :). > > Now, how about we argue about ordering of parameters? > > apt: pkg=name state=installed update_cache=yes > > vs. > > apt: update_cache=yes pkg=name state=installed > > (Hopefully the sarcasm is obvious here... but people have spent a lot of > time bikeshedding on things like alphabetical ordering of CSS properties > <https://www.drupal.org/node/802930>, and we don't need to bog down > adoption of Ansible by being too pedantic about YAML syntax :). > > -Jeff > > > On Thursday, August 28, 2014 11:34:27 AM UTC-5, Patrick Heeney wrote: >> >> I used the second style present by Jeff which involved apt: > format. At >> one time, I don't know how long ago this was in the ansible docs as a >> coding style. >> >> Even with the widest screens available it is very difficult to read >> everything on one line. For version control as mentioned it is also a lot >> easier to break it up. >> >> Take for example this playbook of mine: https://github.com/ >> protobox/protobox/blob/master/lib/ansible/applications/ >> wordpress/tasks/application.yml >> >> It would be difficult to read a lot of those on a single line. The >> drawback if this approach recently broke in ansible 1.6-1.7ish and took a >> week or more >> to be resolved. This required some hacking and back porting to an earlier >> version to get working again. Luckily this was fixed and now unit tested so >> it >> should not happen again. However it is something to be aware of that >> there are more official "syntaxes" that are supported by ansible. >> >> Overall I wish the project had a coding style guide that helps show >> different usages for teams to decide. I for one did not know about the 3rd >> format which is apt: pkg:. >> >> On Tuesday, August 26, 2014 6:40:30 AM UTC-7, Jeff Geerling wrote: >>> >>> Haha, believe me, I've tried a lot of tricks to see how much I could fit >>> on a line :) >>> >>> On Monday, August 25, 2014 4:25:05 PM UTC-5, Michael DeHaan wrote: >>>> >>>> No 4px fonts? >>>> >>>> >>>> >>>> >>>> On Mon, Aug 25, 2014 at 4:36 PM, Jeff Geerling <[email protected]> >>>> wrote: >>>> >>>>> Also, one other thing I forgot to mention, LeanPub in particular, and >>>>> most other publishers as well, has a hard limit of 78-81 characters per >>>>> line for an 8x10 book, so parameter-per-line works out for that nicely. >>>>> Otherwise I'd have arbitrary line breaks all over my code examples, and >>>>> that makes the book incredibly difficult to read. >>>>> >>>>> Until book layouts are fully fluid, that's going to be an issue with >>>>> any published work. >>>>> >>>>> -Jeff >>>>> >>>>> >>>>> On Monday, August 25, 2014 3:33:58 PM UTC-5, Jeff Geerling wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Monday, August 25, 2014 3:25:04 PM UTC-5, Michael DeHaan wrote: >>>>>>> >>>>>>> Yep, style is a team thing. >>>>>>> >>>>>>> Part of this discussion was because Jeff is writing a book, I would >>>>>>> prefer if we didn't advocate that simple key=value on one line was a bad >>>>>>> practice in a book when it conflicts with the core docs, or that >>>>>>> alternatively we should encourage >>>>>>> structured args versus splitting on a line, since there's going to a >>>>>>> point where that's needed. >>>>>>> >>>>>> >>>>>> Exactly why I'm asking here :) >>>>>> >>>>>> I want to present a style that I use and like, but make sure to not >>>>>> say "this is the Ansible way", but rather, "here are the common ways >>>>>> tasks >>>>>> are written... I prefer *this* style (whatever it turns out to be... >>>>>> I'm still not completely sold on any one way as a general rule) for >>>>>> reasons >>>>>> X, Y, and Z, but if you find that one of these other methods works better >>>>>> for you or your team, please use it. The important thing is to use a >>>>>> consistent style that helps you be productive and write effective >>>>>> playbooks... >>>>>> >>>>>> Something along those lines, but basically, since there is no >>>>>> official style guide for Ansible (just examples in docs and the examples >>>>>> repos), and since I see about a hundred different styles in the wild, I >>>>>> want to be comprehensive but not lead people astray. >>>>>> >>>>> -- >>>>> 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/9cfed224-bd34-400f-9ec2- >>>>> 766e80979e0d%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ansible-project/9cfed224-bd34-400f-9ec2-766e80979e0d%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 a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/GfJBkzuTTNM/unsubscribe. > To unsubscribe from this group and all its topics, 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/52f445bf-3dbc-4861-8e81-0d6000c65d39%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/52f445bf-3dbc-4861-8e81-0d6000c65d39%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/CAPEkY-PB%3D8YZNGsPDeeBAfVgg57PLdBP%2B2n7619rPzL3RW2pXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
