-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roles 2.0 #191
Comments
Main thing I'd like to see with |
the requirements file should be able to handle that since now it supports 'dual format' to include roles and collections |
That is a business decision that would have to be over turned. It's purposeful lack of cross type deps due to non-technical decisions. As of now, I haven't heard of any plans to change that behavior. |
@sivel - In that case, what's the point of supporting roles further. IMO that's about the most essential step moving forward if roles are going to continue existing in any form. Right now we're back to the pre-Ansible-Galaxy days of telling people "you're going to have to manually install some things if you want to use this role." IMO it's either make roles 2.0 a thing and make it pleasant, or just abandon it and pour a ton of energy into making role authors happier to migrate to collections (and making single-role collections easier to get going and maintain). What I'd really hate to see is 'roles 2.0' be a half-dedicated effort to make roles better but in reality it just means we fragment the roles out in the world so it's even harder to write Ansible tasks that work across 2.9, 2.10, 3.0 etc. (not to mention |
This proposal doesn't attempt to address those concerns. The concerns that this proposal targets apply equally to stand alone roles and roles in a collection. This proposals target isn't to solve the problems you are concerned with in relation to interoperability between stand alone roles and collection based roles. |
Ah... so roles just in the context of Ansible itself—not the 'ecosystem roles'. In that case, I'll keep fighting those battles elsewhere. For this proposal, a couple minor notes I have:
Handlers are often useful across many different places (I often rely on roles providing them since I architect playbooks to stash all handlers inside roles, e.g. a webserver role would handle webserver restarts, reloads, etc., and I call them from my playbook all the time). Would handlers by default not be global anymore? I don't think I'd lump handlers in the same boat as vars in this case—vars are often very role-specific and don't affect the rest of a playbook, but handlers (IMO) are on a different level.
This honestly seems like it could be the most tricky change. There are some apps and playbooks that depend on the restart happening at the right place in a process, and sometimes I rely on that happening at the end of the entire play / section, other times I call What I really would love, instead, is the ability to do something like: - meta: flush_handlers
handlers:
- my_handler_here
- another_handler Or, alternatively, have it default to flushing only the current role's handlers. That is often necessary in the middle of a role, and sometimes I don't really want to flush all play handlers, everywhere, but that's the only option really. |
How will the magic var
|
@geerlingguy there are many requests for handlers to be 'exclusive to the role', this proposal was trying to add the most flexible version of that. About specific handler execution, that is outside the scope of roles, it is a core engine and I still think it is more appropriate to have tasks with
|
@bcoca These are probably out of scope for this proposal, but some thoughts are:
|
Here's a real world example of me stubbing my toe on the current roles limitations. I created a role Come to find that However, I'm still applying this massive base role with a lot of To make the migration easier, I came up with a plan. There are a lot of files and templates in the NOPE. I can now notify handlers defined in
OK, so, yes, I'm doing things wrong (for someone's definition of wrong, not mine, mind you), but the fact that handlers are visible when I use dependencies infers that the search paths might be able to move in that direction. There are A LOT of these surprises dealing with roles and variables in Ansible. I agree with the @bcoca, Roles need to be better supported and provide the potential to solve the problem I'm fighting. Other CM Systems have clearer, more consistent behavior with dependencies and variable scoping. |
Proposal: Roles2.0
Author: bcoca
Date: 2021--13-32
Motivation
Most users are constantly surprised bye the behavior of Roles, specially when it comes to variable management and handlers
Problems
What problems exist that this proposal will solve?
Solution proposal
New role execution:
semantic versioning (should work just like collections)
private by default (may need a few values/considerations for vars/handlers and to control even explicit exports)
import_role: name=yolo private=false
allow meta declare 2.0 pragma (role author says it works in 2.0 style!)
allow include_role/import_role to force 2.0 execution (play author gambles it MIGHT work in 2.0 style!)
remove 'inline params' as they are confusing and can/will overlap with keywords
create 'always export' facility for vars and handlers (role's purpose is to provide vars or handlers to play)
{vars|default|handlers}/export.yml
no support for meta dependencies , use explicit
meta/requirements.yml
file for installing dependenciesI expect lots of pushback here, but this is to avoid confusion on inheritance since it is reversed but most people expect it
otherwise, while include/import_role are very clear and explicit on how inheritance works.
magic var with 'role_vars' to get access to definitions in roles w/o extra vars or other changes
_role['defaults']['varname']
role's handlers execute at role end by default (currently we do after pre_tasks/tasks/post_tasks)
Testing (optional)
LOTS!
Documentation (optional)
Attach to role argspec/documentation expansion
The text was updated successfully, but these errors were encountered: