Hi,
There’s a few things in Ansible wrt playbooks which I believe would be a little easier if they were tweaked. I’m thinking of submitting pull requests for each of these, and wanted to check first to see if they’d be welcome in principle. They’re mostly small things.
Additional File Extension Support
Most files in Ansible end in a file extension, but there are a few that currently either can’t, or where it currently isn’t suggested. Some text editors still rely primarily on the file extension to work out what syntax highlighting to use for that file. It’d be nice to patch Ansible & docs to add the appropriate file extensions.
- host_vars / group_vars: support .yml file extension too
- inventory: update docs to suggest inventory files end in .ini
Inventory And Playbooks Can Both Live In Sub-folders
At the moment, one of the inventory or the playbook has to live in the top-level folder. ‘basedir’ is calculated from where the playbook is, and Ansible also checks for host_vars and group_vars from where the inventory is. On large, multi-team / multi-platform setups, where there can be quite a few inventory files (last count, I have 20 different files, and merging them is highly undesirable), it’s very desirable to put both playbooks and inventory into sub-folders just to keep things under control.
There’s a few different ways this could be done, but my suggestion is to:
-
make ‘basedir’ be os.getcwd(), and tell users to run ansible_playbook from the top-level folder
-
and update the docs to suggest the inventory, host_vars and group_vars go into a sub-directory
I think that making ansible_playbook look for files relative to where it is running is what most new users would expect; an added bonus.
Add ansible_shell_executable Config Support
The default shell to execute commands and shell with is /bin/sh. This isn’t a great choice on modern Linux systems. It can be overridden by adding executable=/bin/bash in each module call, which not only clutters things up but is a bit error-prone - too easy for someone to forget to add it, and then waste substantial time wondering why their command isn’t working as expected. A quick grep of the Ansible code shows that /bin/sh is also hard-coded as a default value for executable in a number of places.
I’d like to add an ansible_shell_executable host/group var, which defaults to /bin/sh for backwards-compatibility, and to patch out every other mention of /bin/sh in the source code.
Best regards,
Stu
Hi Serge,
Hi stuart,
- host_vars / group_vars: support .yml file extension too
You already can have no extension, .yml and .yaml
see constants.py, YAML_FILENAME_EXTENSIONS = [ “”, “.yml”, “.yaml” ]
I should have looked at _load_vars(). Thanks!
- inventory: update docs to suggest inventory files end in .ini
.ini file as inventory files are not parsed as ini inventory files actually except if your inventory is defined as just that file.
When your inventory points do a directory, .ini file within that directory are skipped. This is to allow them to be confug files for other things, in particular inventory scripts.
I’d agree this can be confusing.
I hadn’t come across being able to use a folder as the inventory before, and it currently isn’t mentioned in the Inventory documentation. I’ll have a play with that.
- make ‘basedir’ be os.getcwd(), and tell users to run ansible_playbook from the top-level folder
That’s what I do, by putting ansible.cfg in that top-level folder, and defining inventory as hostfile = ./inventory/
I’ll have a play with that.
Many thanks,
Stu
Ah - found it. Right at the bottom! Does make me wish that it looked for
a 'main.yml' in that folder which told it what to include. That'd be in
keeping with how the rest of Ansible works (makes it a little easier to
teach new users), and would allow static inventory files to have .ini
extensions.
Many thanks,
Stu
As mentioned above, the .yml extension is already valid.
As for ending in INI, this is personal preference, but as a general rule, Unix systems do not require file extensions for text files, and I’m not super worried about this. A lot of INI files end in .cfg.
As for your discussion about pathing, you really should be using roles in all cases, as they greatly simplify pathing considerations relative to your playbook. Simply drop files into “templates/” and “files/” directories as shown in the roles guides.
I strongly disagree that running relative to cwd is a good idea, and that will not only be a highly backwards incompatible change breaking hundreds if not thousands of playbooks, but will make you now have to worry about what directory you are in. Not good.
“The default shell to execute commands and shell with is /bin/sh” … in what cases are you having problems with the default choice? Generally we want people to not rely on shell commands but to use the various modules, and in cases where you have something larger, the “script” module is a good choice. I don’t quite understand why you would want to set a global default just yet, but want to understand more.
“Does make me wish that it looked for a ‘main.yml’ in that folder which told it what to include”
This will not be changing.
The directory system is there for a good reason, namely you can target hybrid inventory in the top level directory, and target a specific subset by passing in a “-i” of something in the directory specifically.
If you had a main.yml in the directory saying what other directories to include, this would make it hard to switch between which inventory sets you were targetting.
As for extensions, we could definitely add a line that says “you can name this “.ini” if you want and it will highlight in your text editor”, I’m fine with that.
We won’t be requiring .ini.
It sounds like you’re making some kind of role around package installation and want to register a variable by passing in the name, like, “register: package-foo-{{ package }}”. Offhand, I haven’t tried this. Really I prefer seperate threads per topic as this starts to get all confusing in the same thread.
People should definitely not use the script module to install packages.
/bin/sh? Well, right now there’s not a facility for configuring module parameter defaults – it might come later.
As for extensions, we could definitely add a line that says "you can name
this ".ini" if you want and it will highlight in your text editor", I'm
fine with that.
We won't be requiring .ini.
I think that would be very helpful.
It sounds like you're making some kind of role around package installation
and want to register a variable by passing in the name, like, "register:
package-foo-{{ package }}". Offhand, I haven't tried this. Really I
prefer seperate threads per topic as this starts to get all confusing in
the same thread.
Sorry. It was all in the one thread as each seemed too small to merit their
own thread. I'll use separate threads next time.
People should definitely not use the script module to install packages.
/bin/sh? Well, right now there's not a facility for configuring module
parameter defaults -- it might come later.
I'm offering to submit a PR to support this, if it would be welcome.
Best regards,
Stu
I think we’re not quite ready for module parameter defaults, given we want through our planned Runner refactoring first.
There will definitely be a time for this though.