questions about working directory structure

Archives Ansible Developer
1

Hello,

First. I’m a newcomer in Ansible, but i feel it’s very attractive regarding other solutions that i benched before (chef and puppet).
I started to read on Ansible 3 days ago, and forked the repo and installed from source 2 days ago.
I’m pretty new then, but still have common sens of what’s going on since i’ve been working before with others CM tools.

I’m still very curious about the typical working directory structure. I’m not sure about the hosts and playbooks being in the same root directory.

I was thinking it looked a little messy at first sight, and so my journey begun in trying to put hosts in a inventories/ folder, and playbooks in a playbooks/ folder, then go further with making my working directory fit my needs :

I almost succeeded in the first one using the ansible.cfg file that would eventually help to specify a default hostsfile (rather than a default directory) (note that i could also use -i with ansible-playbook, but then some path related side effects would occur regarding vars).

Playbooks would be called directly from command-line, no way to work around that ; but then if in a subfolder some errors would appear : the roles/ folder implicitly had to be at the same level than the running playbook (wherever this one is). I successfully patched this by the definition of roles_path in the ansible.cfg file.

Then, vars. At first i was not sure about why the group_vars and host_vars have this naming convention ; mostly i get it, but i’d rather have a vars/host/ and vars/group/ structure instead, and i’m surprised such configuration is not available in the ansible.cfg file, along with the existing role_path and hostfile.

More than some fashion, the way i patched this need would also allow global (/etc/ansible/) and user (~/.ansible) scope definition for group and host vars by the use of utils.path_dwim in the group_vars loading process and host_vars loading process. Such would be useful for user-sandboxing vars, as for each user could share a common role in /etc/ansible, and would only need to edit the configuration ~/.ansible/vars/host/ to write their own user credentials to connect to a server (for example - that’s a thing we’re currently thinking about in the organization i’m in).

I do agree that the use of utils.path_dwim might totally justify the need for customization of vars directory structure, but it’s still doable, done and default values wouldn’t change the current behavior in other ways than the enhancements i just told before.

My demonstration is a bit off-topic, but it’s mainly to justify the asking of : “why can’t i choose how i shape my working directory ?”

Thanks for reading, and answering,

Regards,
Julien

2

Hello,

First. I'm a newcomer in Ansible, but i feel it's very attractive
regarding other solutions that i benched before (chef and puppet).
I started to read on Ansible 3 days ago, and forked the repo and installed
from source 2 days ago.
I'm pretty new then, but still have common sens of what's going on since
i've been working before with others CM tools.

I'm still very curious about the *typical* working directory structure. I'm
not sure about the hosts and playbooks being in the same root directory.

Two things are key:

This: http://docs.ansible.com/playbooks_best_practices.html

And use roles.

Roles are super key.

Then, vars. At first i was not sure about why the group_vars and host_vars
have this naming convention ; mostly i *get* it, but i'd rather have a
vars/host/ and vars/group/ structure instead, and i'm surprised such
configuration is not available in the ansible.cfg file, along with the
existing role_path and hostfile.

You can put variable files in group_vars/group/<several files> and
host_vars/host/<several files> today if you want to break up files.
That's in tree. Very uncommon, but possible.

More than some fashion, the way i patched
<https://github.com/ansible/ansible/pull/8754&gt; this need would also allow
global (/etc/ansible/) and user (~/.ansible) scope definition for group
and host vars by the use of utils.path_dwim in the group_vars loading
process
<https://github.com/ynk/ansible/blob/feature/configurable-groupvars-hostvars/lib/ansible/inventory/__init__.py#L643&gt; and
host_vars loading process
<https://github.com/ynk/ansible/blob/feature/configurable-groupvars-hostvars/lib/ansible/inventory/__init__.py#L648&gt;\.
Such would be useful for user-sandboxing vars, as for each user could share
a common role in /etc/ansible, and would only need to edit the
configuration ~/.ansible/vars/host/ to write their own user credentials
to connect to a server (for example - that's a thing we're currently
thinking about in the organization i'm in).

Yeah this is over complex for us unfortunately, if everyone doesn't do the
same path conventions it quickly becomes impossible to debug playbooks.
That is very important to me that Ansible User A can tell what is going on
with content from Ansible User B.

I don't follow "sandboxing" as that's usually a security phrase, but see
above about what I said about directories already being in place.

Some could be vault-encrypted, others not, since you are talking about
credentials.

3

First. I’m a newcomer in Ansible, but i feel it’s very attractive regarding other solutions that i benched before (chef and puppet).
I started to read on Ansible 3 days ago, and forked the repo and installed from source 2 days ago.
I’m pretty new then, but still have common sens of what’s going on since i’ve been working before with others CM tools.

I’m still very curious about the typical working directory structure. I’m not sure about the hosts and playbooks being in the same root directory.

Two things are key:

This: http://docs.ansible.com/playbooks_best_practices.html

And use roles.

Roles are super key.

Yep, i’m using roles already :slight_smile: those are very handy i must say. I was more questioning about as hosts and playbooks seems to be semantically different, i was thinking they could have been organized in different folders ; anyway, it seems working with the cfg file so, in the end, nevermind :slight_smile:

Then, vars. At first i was not sure about why the group_vars and host_vars have this naming convention ; mostly i get it, but i’d rather have a vars/host/ and vars/group/ structure instead, and i’m surprised such configuration is not available in the ansible.cfg file, along with the existing role_path and hostfile.

You can put variable files in group_vars/group/ and host_vars/host/ today if you want to break up files. That’s in tree. Very uncommon, but possible.

My point was more into joining “group_vars” and “host_vars” in a semantically joined “vars” named folder first. I understand that i can make subfolders, but as you said “very uncommon”, hehe :slight_smile:

More than some fashion, the way i patched this need would also allow global (/etc/ansible/) and user (~/.ansible) scope definition for group and host vars by the use of utils.path_dwim in the group_vars loading process and host_vars loading process. Such would be useful for user-sandboxing vars, as for each user could share a common role in /etc/ansible, and would only need to edit the configuration ~/.ansible/vars/host/ to write their own user credentials to connect to a server (for example - that’s a thing we’re currently thinking about in the organization i’m in).

Yeah this is over complex for us unfortunately, if everyone doesn’t do the same path conventions it quickly becomes impossible to debug playbooks. That is very important to me that Ansible User A can tell what is going on with content from Ansible User B.

For my own point of view, if i don’t see a group_vars or host_vars folder, i’d look around for a cfg file to check the config, but I do understand this point of view and agree that normalization can be a life saver for debugging.

I don’t follow “sandboxing” as that’s usually a security phrase, but see above about what I said about directories already being in place.

Some could be vault-encrypted, others not, since you are talking about credentials.

I might not have express myself clearly on this one, sorry ! Let me try to clarify : I’ve a machine with ansible installed and several users on it. All of them have a command available that would trigger ansible with a common role (located in /etc/ansible). Each of the users would have to write credentials somewhere containing username/password and others… I was thinking that it could be handy for this usecase to be able to define ansible user scoped host/group vars. This would also be great because user scoped vars means they would be in their respective home folder which is r/w protected from other users of the system.

Btw, I wouldn’t mind if you say that this particular usecase is more like an edge case and should be done otherwise. I was just feeling frustrated not to be fully able to elaborate my point.

Sincere thanks for pointing all of this out,

Julien

4

I don't follow "sandboxing" as that's usually a security phrase, but see

above about what I said about directories already being in place.

Some could be vault-encrypted, others not, since you are talking about

credentials.

I might not have express myself clearly on this one, sorry ! Let me try to
clarify : I've a machine with ansible installed and several users on it.
All of them have a command available that would trigger ansible with a
common role (located in /etc/ansible). Each of the users would have to
write credentials somewhere containing username/password and others... I
was thinking that it could be handy for this usecase to be able to define
ansible user scoped host/group vars. This would also be great because user
scoped vars means they would be in their respective home folder which is
r/w protected from other users of the system.

Yep, this is technically possible by doing group_vars/groupname/<various
files in this directory> and host_vars/hostname/<various files in this

if you technically wanted to do that. You can have multiple

files contributing to the inventory variables.

Another clever option is http://ansible.com/tower, which while it doesn't
allow individual users to own certain vars, it does have a detailed
permissions system and some nice options to allow people to prompt for
particular variables when launching jobs and such. So it has some nice
features if you want some folks to edit variables and not playbooks, or
vice versa. Users could also define their own inventories altogether
seperately without having to worry about the filesystem. That's different
though.

I'm not entirely clear on your use cases - but hope that helps!

5

I don’t follow “sandboxing” as that’s usually a security phrase, but see above about what I said about directories already being in place.

Some could be vault-encrypted, others not, since you are talking about credentials.

I might not have express myself clearly on this one, sorry ! Let me try to clarify : I’ve a machine with ansible installed and several users on it. All of them have a command available that would trigger ansible with a common role (located in /etc/ansible). Each of the users would have to write credentials somewhere containing username/password and others… I was thinking that it could be handy for this usecase to be able to define ansible user scoped host/group vars. This would also be great because user scoped vars means they would be in their respective home folder which is r/w protected from other users of the system.

Yep, this is technically possible by doing group_vars/groupname/ and host_vars/hostname/ if you technically wanted to do that. You can have multiple files contributing to the inventory variables.

Another clever option is http://ansible.com/tower, which while it doesn’t allow individual users to own certain vars, it does have a detailed permissions system and some nice options to allow people to prompt for particular variables when launching jobs and such. So it has some nice features if you want some folks to edit variables and not playbooks, or vice versa. Users could also define their own inventories altogether seperately without having to worry about the filesystem. That’s different though.

I’m not entirely clear on your use cases - but hope that helps!

It does, thanks !