Please do not cross-post. On Thu, Nov 13, 2014 at 12:44 PM, <[email protected]> wrote:
> Hi, this is going to be a cross post to both ansible and salt user groups. > I've spent the last few months going through the docs for both projects and > I know both fairly well. In both cases, the major issue I've stumbled > against is the organization of projects. I've decided to go back to square > one, and have set myself a task of converting some simple shell scripts I > currently use into both ansible and salt to see which tool fits my method > of working better. I'm looking for top level opinions on how to achieve the > following tasks: > > 1 - copy across certain dotfiles to certain boxes (and template some of > them) dependent upon the following: > * box OS (and version if you're feeling ambitious) > * box "purpose" - an arbitrary purpose defined by me - e.g. "private", > "desktop", "router" etc. Boxes may have multiple "purposes". > 2 - install the correct packages and start services based upon box > "purpose". Package-name/service-name will obviously change depending on OS, > so there will need to be a way to keep track of that. > > In other words there will ideally be the following dicts (though I realise > this is not necessarily possible in practice): > * hosts -> list of purposes > * purpose -> list of packages > * package -> OS-package-name > * purpose -> list of dotfiles > > Remember that some of the dotfiles will need to be templated depending on > the purpose(s) of the box, as well as the OS. > > I'm not asking people to do the work for me and I don't need any code, > just an abstract overview of how you would implement this scenario > following "best practices". The idea is to keep the configuration as neat > and simple as possible, but also flexible enough to be easily extended. By > "neat and simple" I mean there should preferably be no duplication of work > (e.g. changing multiple lists in the same way to add a package). By "easily > extended" I mean that additional functionality (such as having dotfiles for > multiple users) should be fairly straightforward to implement and not > involve a complete reorganisation of the config. > > Feel free to use the relevant jargon for the software, but I'd prefer it > if you stuck to core functionality (no hacks/python). > > I'm not going to explain methods I've already looked at as it will only > confuse the discussion, but suffice to say there are multiple ways to > achieve the above scenario in both salt and ansible. I know how it can be > done, I want to know the way you'd do it based upon your experience. > > Flamewars not appreciated. Both tools are extremely capable, but have > different methodologies. I just want to know which fits my own way of > thinking better. > > Thanks for any suggestions > > -- > 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/aed1e318-2adb-41a6-b967-ddaef8dd2877%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/aed1e318-2adb-41a6-b967-ddaef8dd2877%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%2BnsWgz5r%3D%3D6yzk3HPL-3-nW-%3DAbLN%2B105HbCOBGSkH1H5dJmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
