How do you organize your private/internal/org/company Ansible projects?

This sounds similar to @romainquere 's situation that I responded to a few days ago:

The big problem […] [is that] everything seems to be “up a level” above where it ought to be. I’m guessing that your playbooks should probably be roles, and your roles (if you have any) should probably be task files within those roles.

But I’m not throwing stones at your predecessors’ work. When they were just getting started, not really knowing what they were doing, and got something to work, they likely thought, “Okay, that’s how you’re supposed to do it!” and did it the same way from then on. You can dig a really nice, deep hole before figuring out it’s in the wrong place.

I described our setup in that other thread, and as I indicated back in November I’ve started to wonder what we’re missing because we’re using a structure that pre-dates collections.

If you restructure, your choices are “nip and tuck” vs “wreck and rebuild”, although you don’t actually have to wreck; you can rebuild while the old stuff continues to run. But it is worth asking: If you could (or had to) start from scratch, how would you make it look? Being familiar with your current setup makes it really hard to avoid letting the old influence your answer. Only then, though, should you start the process of deciding how to get from where you are to where you want to be. Or to put it another way, be really clear where you want to go before coming up with a transition plan. Above all, don’t just keep tweaking things in the hope that eventually they’ll get better.

That’s way too general to be of practical use, but that’s a luxury I have by being unfamiliar with your setup. :slight_smile: I’m guessing most of us have only really done things one way most of the time, and I’m not confident enough in “our way” to say you should do it the way we do.

Here’s a guideline I’ll throw in for free. I may have come up with it myself, or I might be repeating something I heard way back; I honestly do not know. But it has to do with deciding whether to put something directly in a playbook vs. in some task file. And it’s a guideline rather than a rule, so you’re free to violate it as long as you do so with purpose. Here goes: Playbooks determine what assets to do things to; task files do the things. Not very deep, or maybe profound. I can’t tell! As an organizing principle, it my keep you from digging some holes in the wrong places.

Do follow-up and keep us posted on how you change things. (As my son says often, “I try to benefit from the mistakes of those who take my advice.”)

2 Likes