I posted a quite useful feature request and gave examples with clarification for why the feature is definitely beneficial on many fronts, but it was promptly closed without any clarification or justification as to why it wouldn’t be implemented.
Can the arbiters on the ansible team explain why this was closed? There is NO alternative for the requested behavior in ansible. Ansible’s current behavior causes known problems. Further, it prevents a significant set of features/behaviors for role authors. And the proposed Feature Request solution is even backwards compatible because a new (additive) config property is recommended.
I literally can’t see a single detriment to the suggested feature, and it would help many people out, so I’ll clarify:
When one thinks of dependencies as a general concept, a dependency means “I need this to function or run”, not necessarily when I need it. Ansible currently tightly couples the two concepts unnecessarily.
Can someone please explain why this was closed so quickly?
I've read the feature request. Below is short summary. "role_a" depends on
"role_bar" and "role_foo" [1]. "role_foo" and "role_bar" are imported by
"role_a" [2]. ansible-playbook runs roles "role_foo" and "role_bar" first.
This is claimed to be incorrect [3].
2) role_a tasks/main.yml
- name: Step 1. Do some prep work before running foo
# ...
- name: Step 2. Run foo
import_role: name=role_foo
- name: Step 3. Do some post-role clean up and some other prep work
# ...
- name: Step 3. Run bar
import_role: name=role_bar
- name: Step 4. Do some final work
3) "Calling ansible-playbook will always run role_foo and role_bar first,
before running role_a. This is incorrect because role_a is explicitly
taking control over what roles to run, and exactly when they should be
run, interleaved between various steps in its tasks/main.yml file."
4)
Quoting from the response: "The goal of dependencies is to automatically run
the dependencies for roles ... In general, we do not recommend the use of
dependencies, and recommend providing instructions or a requirements.yml that
allows a user to download the dependent roles used by a role. Alternatives
are to use a collection, ..." https://github.com/ansible/ansible/issues/63923#issuecomment-547011486
Since collections aren’t in a stable release yet, and the documentation on Collections doesn’t explain whether transitive downloads are supported yet, could you please clarify here if they are?
In other words, it’s not so much the format (role vs collection) that’s important. What is important is the transitive auto-download of (collections|roles) based on the seed list.
If I’m a (role|playbook|collection) author, I should have a single requirements.yml file that lists only my immediate requirements. If those in turn have requirements (or requirements that have requirements, ad nauseam), I, the author, shouldn’t have to manually have to walk that dependency tree every time I upgrade a requirement version to see if I need to add those leaf nodes into my requirements.yml file yet again.
Additionally, when running a playbook, the author should only be concerned with the immediate roles declared in requirements.yml. The author should not be concerned about transitive roles (or transitive transitive roles, etc) at all as this completely breaks encapsulation and chain of responsibility.
And:
Because of breaking encapsulation, forcing unnecessary burden on (playbook|role|collection) authors, preventing said role authors from specifying execution order, and preventing a composable library/registry of (roles|collections) that can include other (roles|collections)…
So, regardless of the name of the thing, can transitive auto-download be supported?
Are we on completely different pages here? Does the ansible team understand the value in what I’m discussing? T****here is no documentation on Collections (yet) that actually answers my question.
In Galaxy, nobody is responsible either for the consistency or functionality.
In the end you’re the one to review the code, test the functionality and keep
requirements.yml that can be used in production.
Yes I agree, but IMO that doesn’t change with roles having a meta/requirements.yml file either. You still must test with molecule or other similar mechanisms.
If I understand you correctly, what you’re saying - that one should manage every dependency possible in a single requirements.yml file - is akin to using pip, ruby gems, maven, gradle, etc, and forcing the project author to manually traverse every project requirement in the dependency tree and declare them manually. If that’s what you’re implying, I’m sorry but I very much disagree - it’s just not feasible, necessary, or even a good idea at any reasonable scale. Countless production applications in the world depend on the transitive nature of these package management systems, and things work perfectly well overall, and there’s no reason why ansible roles couldn’t either.
The reason why this transitive model works is that we test. If a Galaxy role is versioned, you test it with your role or playbook with molecule and in a CI environment, plain and simple. This strategy works well enough to rely on it before using something in alpha/beta/prod.
But regardless of whether we disagree on this point should not matter IMO. I believe ansible should let the user decide. Role authors could choose (or not) to include meta/requirements.yml files as they see appropriate. ansible-galaxy users can choose to specify (for example) a --no-deps option to explicitly disable transitive requirement downloads if they desire. The point is that the ansible user should determine what is right for their particular environment or testing strategy.
My initial ansible-galaxy wrapper implementation seems to satisfy my needs for this, but I feel it is unfortunate that it isn’t available to everyone natively.
My hope is that the ansible team will enable this relatively simple behavior (it took me less than a day to write). I’m sure many of us believe it to be essential for composable roles and playbooks.
