I’ve considered making a contribution to Ansible for this, but I wanted to throw the idea out there to make sure I’m not running against prevailing wisdom, or in case my Google-fu isn’t finding the answer that’s already out there. I’ve noticed in my team’s collection of Ansible roles (25-or-so of them) that we have a total of 69 distinct “main.yml” files. In our case, this also means we have 69 parent directories (like “foo/meta” and “foo/tasks”) which exist solely to organize and contain a single “main.yml” file. It also means that in my editor, I might have several “main.yml” files open, and it’s harder to tell which is which as I jump back and forth. This nested file organization feels like overkill for our particular case. Do most folks tend to further break apart their “main.yml” file such that the extra directories really do help with organizing?
In our particular case, I’d find it much cleaner to compact cases like “foo/meta/main.yml” and “foo/tasks/main.yml” to “foo/meta.yml” and “foo/tasks.yml”. Admittedly, I’d still have 25 “tasks.yml” and many "meta.yml"s, and so on… but it wouldn’t feel quite so unwieldy. Would optional behavior like this be welcome? Or would having two ways to specify these files make things more confusing for folks?
(I’ve tracked down the location in v2/ansible/playbook/role/init.py where this could be easily changed… but with “v2” in the path, I’m not sure if that’s actually part of the 1.8.x code or not.)
A standard has already been established, any change would require looking in multiple locations, which introduces ordering issues and complexity. I’d rather the standard stay as it is at the expense of a few more main.y(a)ml files.
From what I can see, the current code already checks for multiple names, if not locations: “main.yml”, “main.yaml”, “main.json”, and “main”. Adding support for a non-nested variation of the file doesn’t seem like it’s adding that much more complexity, and the slight increase in complexity is leveraged against hundreds or thousands of places where the playbooks can now be simplified.
Interesting… while I can see how it helps the “distinguishing files in an editor” issue, having a bunch of boilerplate “main.yml” files that just include the real file also seems like a lot of noise. My goal, coming at this form the standpoint of (a) someone who’s relatively new to Ansible, and (b) has to explain it to people who are completely new to Ansible, is to make the layout and structure of our role playbooks as simple and straightforward as possible. Having all of the important files as singletons in their enclosing directory, and named “main.yml” invariably leads to the question “why?”, to which I can only answer “because that’s how it is.” Having “tasks.yml”, “meta.yml”, “vars.yml” etc. inside each role directory would require almost no explanation beyond the idea of tasks, role dependencies, variables, etc.
We check for multiple names, we will not be supporting one combined YAML file, as we want everyone to write interchangable YAML and not have dialects diverge.
I’m not sure how to interpret this. I think you’re saying “we won’t merge files, we look for multiple names, but only actually load one file”. I’m not asking to merge/combine files, I’m just asking about the idea of adding to the list of files/names used in the “find the first match and load it” list. Unrolling the v2 code a bit, when the “tasks” file is looked for, the following files are considered (the first one found is the one–and only–file actually used):
The current behavior would continue and be the default; the newly-added names would only be checked if none of the first four files were found. This would have the potential to break/alter behavior in the case where someone had no “tasks/main” variant, but did have a “tasks.yml” file… but that seems fairly unlikely.
Fair enough. I can totally see that the design is optimized for the more-complex case, and makes refactoring/splitting files a bit more straightforward. I do think there’s value in the simple case, and would be curious about empirical evidence for each side of the discussion… but not so much that I’m going to spend time collecting it.
Yep, thanks for understanding - I do feel for your editor problem a bit. less of an issue with vim I guess.
Visual Slick Edit had a most excellent file system tree in the mid 2000’s … just showing the filename seems to be a step back and can’t find anything I like as much
I love Ansible for how simple and easy to understand it is, so this is bothering me as well. I have some very small roles (roles! roles are great ;)) that only have a couple of tasks and variables to them, and I would love if I could just have myrole/tasks.yml and myrole/vars.yml. Now I have to add another directory layer for a something that is 30 lines of code, and it feels a little like Java bureaucracy (with its src/main/java/oh/my/god/ paths).
Actually, Ansible does something similar when it comes to group variables: one can have either single group_vars/all.yml file or group_vars/all/ directory containing multiple files. If we do it this with group_vars, why not do the same with role files, for consistency’s sake? I would be willing to write a patch if you would accept the idea.
I second this… it seems unnecessary to have the directories in most cases. I frequently have a vars/main.yml file that has only a few lines in it.
Also this makes it difficult to find the right file in the tabs of my editor because they are all named main.yml.
