So if I have a role with this as their meta:
The “when” conditional is properly being applied to both tasks in this scenario, by design.
This seems like the most logical behavior, because the parent role has decided to not be included, so the dependencies should have the same conditions.
Also, this is not an inheritance model. This is a dependency model.
Maybe I’m misunderstanding the dependency model if the current way is working in the most logical way. I consider
roles as jobs and tasks as things the job needs to do.
If I have two jobs: being a parent and a restaurant cook, one of the tasks of both of these jobs is doing the dishes. If I
stop being a restaurant cook this doesn’t mean I get to stop doing dishes as a parent.
Would love to understand this model more and why skipping a role would mean that any others roles who have explicitly
defined dependencies would be ignored.
A more real world example of my problem is we are experimenting with both gunicorn and uwsgi and so depending on some
facts gathered we want to install one or the other:
-
{role: gunicorn, when use_gunicorn=true }
-
{role: uwsgi, when not use_gunicorn=true }
-
gunicorn
-
{ role: python }
-
uwsgi
-
{ role: python }
So in this use case, when we decided a specific server should be uwsgi ansible has decided that uwsgi doesn’t depend on python because gunicorn depended on it and we don’t want to be a gunicorn server.
If I have two jobs: being a parent and a restaurant cook, one of the tasks
of both of these jobs is doing the dishes. If I
stop being a restaurant cook this doesn't mean I get to stop doing dishes
as a parent.
Yes, but you probably will have other tools as a cook and as a parent.
Parameters differ. You also do that in other locations.
So, in this example, you would have to do it twice: at work and at home,
each with their specific parameters,
Would love to understand this model more and why skipping a role would
mean that any others roles who have explicitly
defined dependencies would be ignored.
So in this case, one of the parameters is a conditional that should not
apply to the other case. So you need to have this dependency as a double,
separate dependency with their won parameters.
Which means you need to allow duplicates.
Serge
In your original note:
The problem is the role is higher level, these roles are never declared in the playbook. The full set looks like this:
They playbook:
surveymonkey.yml
-
hosts: “auth_web_servers”
roles: -
usersvc
-
hosts: “main_web_servers”
roles: -
surveymonkey
and then those roles:
roles/usersvc/meta/main.yml
dependencies:
- { role: gunicorn, when: use_uwsgi is not defined }
- { role: uwsgi, when: use_uwsgi is defined }
roles/surveymonkey/meta/main.yml
dependencies:
- { role: gunicorn, when: use_uwsgi is not defined }
- { role: uwsgi, when: use_uwsgi is defined }
roles/gunicorn/meta/main.yml
dependencies:
- { role: python }
roles/uwsgi/meta/main.yml
dependencies:
- { role: python }
Are you saying I can declare roles inside meta/main.yml instead of dependencies?
Nope, just saying that was a quicker problem.
It seems you are modelling role dependencies a bit heavy. People will disagree, and they silenced some important concerns from people who really felt they needed them, but I actually encourage not using role deps for most cases.
What Serge said above about enabling duplicates should resolve your question.
Yeah, duplicates is how I solved my problem in the short term but this made it so my roles run tons of times and it slows my script down by an hour because some of my roles that would need to be marked as duplicates are all the common things that can be inherited but only ran once, so things like checking if there is a new version in git, installing common packages etc.
I seriously suspect you don’t need role dependencies.
Just put the things in your roles you need, or call setup roles before other roles.