Resolving some ambiguity with requirements.yml vs meta/main.yml

[mahmoudimus]

Hi there,

I would like some clarification on this pattern I'm noticing in the documentation in regards to dependencies installed via Ansible Galaxy (http://docs.ansible.com/galaxy.html) and the Role Dependencies (http://docs.ansible.com/playbooks_roles.html#role-dependencies).

When would you choose requirements.yml over a meta/main.yml with its dependencies list filled out? There might be some unnecessary duplication.

The only thing I've been able to reason was that you would use meta/main.yml dependencies when the intent is to distribute the encompassing role. 

If one has playbooks that require specific roles installed, one would put them in the requirements.yml.

So for distributable roles that also have playbooks, it is assumed that if one is operating on that role directly, then requirements.yml is necessary. If one is embedding that role, then meta/main.yml should define the dependencies that are required to embed that role.

Not sure if my understanding is correct.

Thanks for the help.

[Michael DeHaan]

The requirements file is a way to pull down everything your package would need, from different repos, possibly specifying different versions and sources.

The role deps file is really only intended for Galaxy, to work as a package manager, for things that are also on Galaxy.

Requirements.yml isn't required for anything on galaxy, or for sharing roles, but is meant as an analog for specifying a list of roles to suck down.

For instance, suppose you have 5 types of servers to deploy.   One type of server uses 10 roles, another uses 2 roles, another uses 3 roles.  You might have one requirements.yml that says "download all these roles", and it gets your ansible checkout ready to go.

Dependencies don't just suck down roles - they make sure those roles are *applied*, so it's inappropriate to have a role that says "everything.yml" with just deps, when they are unrelated concerns.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7874cc03-0ee4-4b68-8cb6-acd3180091d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Harvey]

Hi there, 

I am still not 100% clear on this.

I have a role for Sonatype Nexus, and it requires a JDK v1.8.  I would like to use my role in conjunction with Jeff Geerling's Galaxy Java role, and this role by default will install JDK v1.7.  I would like the users of my role to have the experience that everything works right out of the box, as it were, so I therefore want JDK v1.8 automatically installed.

In Puppet you'd do something like this:

# params.pp
class nexus::params {
  $java = 'java-1.8.0-openjdk'
}

# init.pp
class nexus ($java = $::foo::params::java) {
  class { 'java': package => $java }
  ...
}

# metadata.json
"dependencies": [
  {"name":"puppetlabs/java","version_requirement":">= ..."}
]

Am I correct in thinking that this should be implemented in Ansible as:

# meta/main.yml---
dependencies:
 - { role: geerlingguy.java, java_packages: ['java-1.8.0-openjdk'] }

# playbooks.yml
---
- hosts: nexus.example.com
  roles:
  - geerlingguy.java
  - ansible-nexus

Also, if not, in what circumstance would we pass data into a role via meta/main.yml?

Note that I have the following unanswered question at Stack Overflow:

http://stackoverflow.com/questions/37373464/ansible-test-kitchen-passing-array-data-into-dependent-module

However, I believe this could be a bug within kitchen-ansible.

All the best,

Alex