Peter, Of course roles can be understood and used differently. I was trying to explain how I view and use them. This was to show why I thought (and still think) that a role based limit was needed as a command line option. The view of roles as just a bunch of tasks doesn't sound right to me from a user perspective (no matter if they are implemented that way) so I was explaining my reasoning.
As for terminology I use "baseline" and "configuration item" (CI) according to normal usage in the CM context (see IEEE 828-2012 and ISO 10007:2003). Unfortunately "CI" is frequently used to mean continuous integration (like with Jenkins) so that's confusing. CM requires a baseline and a set of CIs. My question was, if people are not using roles as a CI then what are they using? In other words how are you tracking the versions of your baseline and the versions of the changes you make using Ansible? As for best practices, I would say instead that best practices are the same only how they are applied differs. Regards, Aaron On Saturday, April 26, 2014 6:37:45 PM UTC-4, Peter Gehres wrote: > > On Sat, Apr 26, 2014 at 2:41 PM, Aaron Hunter > <[email protected]<javascript:> > > wrote: > >> >> I don't view roles as "just abstractions around tasks." In fact just >> the opposite: tasks are the commands needed to implement a role. >> > > A role is a self-contained set of tasks and related files and templates > that make a host do something. For example, act as a DNS server. Our DNS > server could also be our DHCP server and maybe also an LDAP slave. > > We use cobbler for our host management and use cobbler.py as our inventory > file for ansible runs. Each role is represented by a "management class" in > cobbler which then results in the host being a member of a group. For each > role in our playbooks we have a play that executes that role on hosts in > that group. Many of our hosts have multiple "management classes" attached > to them and thusly multiple roles get applied. > > This is because I use roles as my primary CI. The baseline on a given host >> is made up of applications (a CI) and roles (a CI) and some hardware stuff. >> All the CIs are version per good CM practice. >> > > I'm not following. Are you not deploying applications via roles? What does > hardware have to do with this? > > >> If you are aren't using roles as your main CI then what are you using as >> the CI's in your baseline? The entire playbook? An individual task? >> > > What do you mean by "baseline?" In our environment every host has a set of > roles. We have a "common" role that is applied to every host and then we > apply other roles as well to make a host, say, a webserver (maybe "mysql," > "webserver," and the role name for the application it will run). > > How Ansible maps to and supports a formal CM process is an important >> question, at least to me. As my CM tool of choice I hope to see Ansible >> evolve in a way that facilitates CM best practices. >> > > Where do you see ansible standing in your way? What are you trying to do? > Also, "best practices" are not always the same between environments. > > > > -- > Peter Gehres > Site Reliability Engineer | AppDynamics, Inc. > www.appdynamics.com | AS62897 > -- 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/408a6a5c-d4c2-4e1d-96be-83fe1927c50c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
