4 ms·

Agreed. In fact variables are scoped by "play" not by "role" which is almost weirder. For those who don't know the organizational structure from largest to smal

Agreed. In fact variables are scoped by "play" not by "role" which is almost weirder. For those who don't know the organizational structure from largest to smallest is playbook->plays->roles->modules/tasks. Variable scope is at the "play" level. More than that, roles are meant to be distributable components on the Ansible Galaxy service they run. Galaxy gets almost no use because modularity and reusability is broken by having no idea how the role author namespaced their variables. Collisions happen all the time. Why we must manually manage scope with naming conventions when the computer can do it automatically with scope is beyond me. This is Ansible's biggest downside in my opinion. I've talked with the core devs about it on IRC and they (bcoca) agreed but thought it too late to make such a pervasive change as introducing role-level scope. As some of the other posts have mentioned, I still love Ansible despite this shortcoming.

andrewvc 11y ago
Can't agree enough here. The core deva act like it isn't a problem. The lack of encapsulation makes reusability impossible
- krakensden 11y ago
  I remember being really down on Ansible Galaxy, and whenever someone tried to use a community role, I'd pull it down, audit it, and make them fork it, because it was inevitably dangerous, not thought out, and with no tests. Now I'm back in a Chef shop, and Chef has a ton of tooling for re-usability, has put loads of thought and effort into the problem, and there are tons of cookbooks, many maintained by Chef, Inc. The problem isn't really any better though- the official and officially blessed cookbooks are still terrible, broken and unsafe in all sorts of obvious ways. I'd rant more, but I'd have to get specific and mean about actual people. It's the problem space, honestly. It all depends on the guardrails your workflow provides, and there's never enough in common. Anyway, there's a reason everyone loves golden-images.
  - LukeHoersten 11y ago
    Good point. The Ansible community who happened to be talking to me on IRC about this basically said that at least at this point, you have to look at all your role code no matter what anyway. Meaning scope wasn't the core issue. But lack of variable scope even hurts my own Ansible config abstractions.

andrewvc 11y ago

Can't agree enough here. The core deva act like it isn't a problem. The lack of encapsulation makes reusability impossible

krakensden 11y ago
I remember being really down on Ansible Galaxy, and whenever someone tried to use a community role, I'd pull it down, audit it, and make them fork it, because it was inevitably dangerous, not thought out, and with no tests. Now I'm back in a Chef shop, and Chef has a ton of tooling for re-usability, has put loads of thought and effort into the problem, and there are tons of cookbooks, many maintained by Chef, Inc. The problem isn't really any better though- the official and officially blessed cookbooks are still terrible, broken and unsafe in all sorts of obvious ways. I'd rant more, but I'd have to get specific and mean about actual people. It's the problem space, honestly. It all depends on the guardrails your workflow provides, and there's never enough in common. Anyway, there's a reason everyone loves golden-images.
- LukeHoersten 11y ago
  Good point. The Ansible community who happened to be talking to me on IRC about this basically said that at least at this point, you have to look at all your role code no matter what anyway. Meaning scope wasn't the core issue. But lack of variable scope even hurts my own Ansible config abstractions.