# galaxy roles from groover **URL:** \ **Category:** Ansible Project\ **Tags:** galaxy-ng\ **Created:** [June 10, 2015, 5:14pm UTC](https://forum.ansible.com/t/galaxy-roles-from-groover/18461 "2015-06-10T17:14:02Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![mark.kusch](https://avatars.discourse-cdn.com/v4/letter/m/8e8cbc/32.png) [@mark.kusch](https://forum.ansible.com/u/mark.kusch)\ **Post date:** [June 10, 2015, 5:14pm UTC](https://forum.ansible.com/t/galaxy-roles-from-groover/18461/1 "2015-06-10T17:14:02Z")
Hello list, I thought to use this forum to drop some lines for concepts and updates to roles in galaxy provided from user groover (e.g. groover.tomcat). We often had issues reported on github in open source roles regarding local\_action: get\_url tasks requiring sudo/become: yes and failing the plays when no passwordless sudo was available to the users. The concepts here are quite simple: - Make downloading assets persistent   - Download from third party once   - Upload to internal network as often as required - Allow any user with access to a central Ansible node to download   assets from the internet in a persistent place (e.g. NOT /tmp)   - This would require to manage a directory, where all users could     - write to     - read from     which resulted in a task      - name: Install persistent local data path   become: yes   local\_action: file     state=directory     dest=/usr/local/...     owner=0     group=0     mode=2777 Many people out there do not need that, but we do, even if a big number of playbooks is now managed with a continous integration system. More on that later on. We often found to be very repetitive with tasks in roles. Like the persistent local download path above. Many roles had this task and we started to share variables (like namespace clashing) over different roles (e.g. {{ ansible\_local\_data\_path }}). Not a good idea. But we did that. What I really wanted to do was to give you all the power to configure the roles to your needs, and there was thankfully one Ansible feature evolving and totaly functional with the 1.8 releases. Dependencies. In earlier versions a dependency was triggered as many times as it was called from roles, so using groover.java and groover.tomcat roles both depending on another role would have meant the dependency to run at least twice. If we add the dependency to the playbook for more transparency even three times. This changed with Ansible 1.8 and using dependencies started to make sense. What I really NOT wanted to do is spam all the roles with all different dependencies and tell you "if you want to use my tomcat role, you have to use everything from my playbooks". So, here at silpion ([http://silpion.de](http://silpion.de)) we now treat two different types of dependencies. - soft dependencies - hard dependencies We only add hard dependencies to roles' meta/main.yml dependencies dict. This in turn allows to safely use variables from other namespaces (all our roles use the role name as prefix to variables, e.g. tomcat role prefixes all variables with tomcat\_) as we can ensure that the variables are known to the Runner. We have a hard dependency configured. There are still issues with tags, but that's another story not completely solved right now. Soft dependencies can get used to fulfill the requirements a role may have, but it's up to you (all the power again) to either use other roles from silpion, or to fulfill the requirements yourself (e.g. local facts like {{ ansible\_local['java']['general']['java\_home'] }} for the tomcat role). We decided: We need dependencies. We also decided that if we use dependencies, we keep them as few as possible. So, if you don't like dependencies, I'm sorry, but I'd rather use a good dependency in favor of all roles repeating tasks and burning CPU. We came up with a single role, which should help us to get rid of repetitive tasks and to even better make complete playbooks configurable with single variables from that role. groover.util was born. The util role is not meant to configure nodes. (It does that regarding installation of Python selinux bindings, or the EPEL repositories for ansible\_os\_family == 'RedHat', but that's for a good reason.) The util role is meant to configure aspects of Ansible and playbooks and to ensure Python libraries Ansible requires for our roles are available on the nodes. An example. - hosts: test-environment   vars:     util\_package\_state\_debian: latest   roles:     - { role: groover.java }     - { role: groover.tomcat } - hosts: production-environment   vars:     util\_package\_state\_debian: installed   roles:     - { role: groover.java }     - { role: groover.tomcat } All roles depending on groover.util role will have this implemented whenever they use the nodes package manager to install packages. That's the idea, basically. util role is our starting point for anything. It does a few but very powerful things. That is why a number of our roles developed at silpion will have a dependency to the groover.util role in the very near future. What else. util role will make the local\_action: file task from above completely configurable, once v2 has arrived. Currently there is an issue with Ansible itself which is fixed with v2. The following roles will get updates for that very soon: - groover.etckeeper - groover.java - groover.tomcat - groover.maven - groover.heka Roles from cascaya will follow this as well in the future. Please be aware of one more thing to note regarding our method of dependencies: At the time we created our galaxy accounts there was no organisations feature most of you might know from github. We do not configure dependencies on `groover.tomcat'. We configure dependencies on our organisation, silpion. Each role has a requirements.yml file distributed which stores our roles as silpion.tomcat, silpion.java, et cetera. What else. Active pull requests. Because we have changed a lot of roles we cannot just merge pull requests on github until the "move" is final. I try the best I can to integrate features requested. In the process we updated the tomcat role for various feature requests and issues without staying backward compatible. I personaly think it was worth it. You'll see. That's it. I'd add potatoes. Hope you find this useful in whatever terms/means and understand, - why we start to use dependencies - that we were forced to disregard backward compatibility in tomcat   role. Best, # kraM (groover@galaxy, spul@github, kraM@freenode)