nested roles

788 Aufrufe
Direkt zur ersten ungelesenen Nachricht

John Petro

ungelesen,
17.06.2022, 16:26:5517.06.22
an ansible...@googlegroups.com
I have a question regarding nested roles. 

Back Story:  I am doing some code reviews for some ansible code a coworker has done.  I noticed that they are importing other roles into the role they are working on.  

Question:  I feel like this is not a good idea, that dependencies should be taken care of at the playbook level, but I am having a difficult time justifying why nesting roles is not necessarily a good idea, so I am looking for some feedback to help me here.  I welcome your thoughts on this...

--John

Paul Manno

ungelesen,
18.06.2022, 11:33:5518.06.22
an ansible...@googlegroups.com
Hi John, 

Per ansible doc, you should not import a role within another role. Instead, you should use the built in dependencies model. Importing a role in the tasks of another role is a bad idea because it reduces the portability of the role. You'd have to guarantee that the role you're using and the role you import are both present in your roles dir. The dependency model ansible provides solves this problem by leveraging the ansible galaxy command to pull dependencies from remote repositories. 

Paul

Sent from my T-Mobile 5G Device
Get Outlook for Android


From: ansible...@googlegroups.com <ansible...@googlegroups.com> on behalf of John Petro <jcp...@johnpetro.com>
Sent: Friday, June 17, 2022, 3:26 PM
To: ansible...@googlegroups.com <ansible...@googlegroups.com>
Subject: [ansible-project] nested roles
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAPAjob8sDH_4Sz23MFPTsBiB0wzmokOKmyJdfkGdsPY6nTZchQ%40mail.gmail.com.

flowerysong

ungelesen,
19.06.2022, 00:45:2719.06.22
an Ansible Project
I highly disagree with this, and would be interested in a pointer to the documentation that you say claims "importing a role in the tasks of another role is a bad idea" since I've never seen that in the official Ansible documentation.

Explicitly importing or including the role provides more control over execution order, and ansible-galaxy can still handle dependency install by listing them in meta/requirements.yml (https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#using-meta-requirements-yml)

Paul Manno

ungelesen,
19.06.2022, 10:30:0119.06.22
an ansible...@googlegroups.com
Hello flowerysong,

I'm sure it was the case, at least with older versions of ansible, that the doc included a statement that roles should not be included from other roles and that the dependency mechanism should be used instead. Looking at the link you posted, that feature has only been available since v2.10. I'm using AWX, running 2.9, and the official RedHat ansible tower is only up to ansible 2.9.27. That suggests that the feature you're referencing wouldn't even work in Tower or AWX? Are you using tower and/or AWX and are you able to use that feature? Another question world be about dependencies for the roles you import because older roles may still use the older meta/main.yml which would not be evaluated on role import? 

So maybe we are finding even more reason to not import roles in roles due to backwards compatibility issues? 



Sent from my T-Mobile 5G Device
Get Outlook for Android

From: ansible...@googlegroups.com <ansible...@googlegroups.com> on behalf of flowerysong <ezek...@umich.edu>
Sent: Saturday, June 18, 2022 11:45:26 PM
To: Ansible Project <ansible...@googlegroups.com>
Subject: Re: [ansible-project] nested roles
 

John Petro

ungelesen,
19.06.2022, 21:23:2219.06.22
an ansible...@googlegroups.com
Paul,
  Thanks for that feedback.  Definitely some things to think about here for sure.  I thought I had remembered reading somewhere that is wasn't a great idea, and was not able to figure out where I had read that so I am glad you brought up that it wasn't recommended with earlier versions.  My thought, is that if a role is being imported inside a role to make sure that dependencies were met, that it might be better done in the master playbook, instead of the role to make debugging easier.  I am sure there are other reasons too but that is one of the first things that came to mind.

--John

Brian Coca

ungelesen,
21.06.2022, 10:39:4521.06.22
an Ansible Project
@Paul Mano the features @flowersong mentions are for installing, not
running the role. There has never been advice to use dependencies over
importing a role. I have personally always advised the opposite, I
created import_role/include_role because the dependency mechanism is
very counterintuitive. I think you are mistaking the misuse of include
(used as current include_tasks) or include_vars targeting 'files from
a role' vs importing the role itself, this WAS advised against (still
is).

2.9 is EoL as is 2.10, the import_role/include_role features were added in 2.4.
--
----------
Brian Coca

Paul Manno

ungelesen,
21.06.2022, 10:52:0621.06.22
an Ansible Project
Hi Brian,

Wow... I could have swore I read that you should never import a role from another role: That is to say that in a role's tasks/main.yml to do import_role for some other role.  This made sense to me since a role, I thought, was supposed to only do one thing and do it well.  Importing one role from another would seem to inherently do more than one thing, and chaining roles like that could exhibit unpredictable behavior.  On the other hand having a playbook that chains import_role, of course, is fine and I get that.

So are you saying that importing a role from another role is an OK thing to do?

Paul

Brian Coca

ungelesen,
21.06.2022, 11:45:2321.06.22
an Ansible Project
I prefer to keep things simple and obvious, I would keep role imports
to the play, not everyone agrees and many use complex role
hierarchies.

If it is a choice between setting 'dependencies' (which imports a role
from a role) and import_role, I always advise to use the latter.
reasons against dependencies:
- it is hidden in the 'meta' so it adds 'yet another file' to find out
the task flow
- they execute prior to the role with a lot of rules to which
variables and keywords are inherited
- the dependent is also the parent, which many find counterintuitive
- the import always happens, conditionals are appended to the
tasks/handlers on execution

with import/include:
- inheritance is clear, set at the time of import/inclusion (import
directly, include via apply option)
- with include_role you can avoid importing at all, import_role
behaves closer to roles:/dependencies
- finer control on when to execute
- you can dynamically choose the role and/or entry points for the role
(tasks_from/vars_from/etc)

Currently the only advantage of dependency over include/import is that
it is both runtime and install time so you don't need to add the role
to 'requirements' file, which can be dealt with if we automate
requirements file creation (some issues with dynamic role selection,
but should work for static references).

----------
Brian Coca

John Petro

ungelesen,
21.06.2022, 15:26:2821.06.22
an ansible...@googlegroups.com

Brian Coca

ungelesen,
21.06.2022, 18:13:3921.06.22
an Ansible Project
Yes, but that is not a commonly held view, why 'dependencies' exist,
so I suggest using import/include_role instead ... if i cannot
convince people of avoiding role 'trees'.


--
----------
Brian Coca

John Petro

ungelesen,
21.06.2022, 18:20:3121.06.22
an ansible...@googlegroups.com
That's really where I come down.  I'd rather see all dependancies in the playbook, to avoid potential problems down the road. 

--
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.
Allen antworten
Antwort an Autor
Weiterleiten
0 neue Nachrichten