“This does kinda solve the issue, however we want to treat the role as readonly because changing it could break other playbooks.”
Ok, I’m confused now.
What does “readonly” mean?
Just don’t modify the role in source control?
I think Dennis’s reasoning is good. I would also find this feature practical. Would it be possible to do a core module called ‘role’?
Not seeing post from Denis on this thread - can you provide a link?
Roles to download roles are possible, via something that uses
ansible-galaxy's CLI, though we need to refactor that a bit first (the
ongoing v2/ tree code) to make that more easy to access.
It is the current thread: Roles, tasks and composability
https://groups.google.com/forum/#!topic/ansible-project/9bghHncUQCM
Ok yeah for now I’d just do a playbook that calls the ansible-galaxy install command using a requirements file.
In 1.8 and later this can also suck down Ansible roles.
Once the v2/ refactor is further along I can see a module doing this and roles being a bit more lazy loaded to allow runtime in the same playbook possibly.
I’m not sure if we are talking about the same thing. Dennis didn’t speak about lazy loading roles on demand, but running role as a task so you could do custom stuff between role execution. With core module called ‘role’ I meant (as Dennis suggested) this:
-
name: configure repo for patched mysql server
copy: src=my-repo.repo dest=/etc/yum.repos.d/my-repo.repo -
name: install and prepare mysql
role: mysql-server root_password=test -
name: add additional mysql user
mysql_user: name=admin host=‘%’ … -
name: register this database server with several external services
role: register_db_server
There will not be a task that applies roles, the “role” directive is for this.
There will not be a task that applies roles, the “role” directive is for this.
But, AFAIK, the “role” directive can only be applied from a playbook, not from another role. So, if the task suggested by Juho will not exist, how can you apply to a role the logic that is wrapped as another role? The only way I know is using dependencies, but those are always applied before the role’s tasks are applied. And sometimes you need to run tasks before a dependency is applied (something equivalent to playbooks’ pre_tasks, but for roles). Is there a way to do this? I’m pretty new to Ansible so I may be missing something.
Thanks,
Jaime
Is there a technical reason for this?
I’ve only been using Ansible for a few months, but from what I can gather the project has evolved to the point where roles and tasks and includes can pretty much do all the same things - they’re all invoked with either [name of role / task / include file.yml] and a bunch of ‘key=value’ arguments, so it seems like it’d be cool if there was a unified way of invoking them. Perhaps something like:
‘action: mysql-server foo=bar’
and then leave it to Ansible to figure out where to look for ‘mysql-server’ (either in library/ roles/ or mysql-server.yml). These ‘actions’ could just be listed in the order they have to be executed, then you wouldn’t need pre-tasks, roles and post-tasks, or seemingly arbitrary restrictions such as ‘you can call a task from a role but not a role from within another role, or you can - but only before any tasks from that role’ - it’d just be one unified concept.
I believe I’ve got similar usecase except my starting point is different. I found that parametrized includes do exactly what I need so there’s no issue with roles vs task includes. However while roles have a defined search path and allow for central repo of roles, includes can only be in the same directory or referenced using full/relative path which doesn’t allow for portability.
Here’s one of my examples:
I’d like to configure certain network interface on the machine, however I would like to locate it based on it’s MAC address and then do the rest of config based on that. So it’s like a “function” in typical programming language - some inpts are given with some outputs expected. Making it a role works only to a point - that means I have to either use “dependency” from other roles to invoke it mid-play or use it directly from top-level play. With “include” statement I can use it inline but then I have to sacrifice portability and provide full path. For some of my other usecases building modules is impractical since it has to operate on several machines - thus using playbooks is more natural.
To put it short - we already have “library” and “roles_path” for dealing with central location of those items. Can we also have “includes_path”? This should close the gap that currently exists due to roles being allowed only at top-level playbooks.