Michael DeHaan <[email protected]> napisał: >"If role B depends on role A it cannot use values for variables >provided by >A unless these values are specified globally, e.g. in group_vars/all." > >Role variables in the "vars/" directory of a role are actually pulled >into >all roles. I think the proposed include_defaults task would be useful because of this - it would add an easy way for providing OS-specific defaults without cobbling other roles namespace.
>"- several people using ansible are baffled by the inability to >override from the inventory the variables set by a role" > >We've explained this many times when folks have precedence questions. >Many things have greater precedence than inventory variables, including >role parameters and variables in the roles. Defaults are actually >lower >precedence. > >Again, I'd prefer to work back form the use case of what you are trying >to >model to see if things can't be solved by existing systems, continuing >to >add more syntax increases the cognitive load of the program, which is >something I like to resist :) > > > > > >On Thu, Aug 28, 2014 at 4:48 PM, Daniele Varrazzo < >[email protected]> wrote: > >> Hello, >> >> after yesterday's thread I've goggled a bit more around ansible and >> variables and I've figured out the following facts (of which many of >you >> are probably aware but I'm new of the environment): >> >> - the precedence of the variables is set in stone: a lot of people >rely on >> that and tweaking it is out of discussion; >> - several people using ansible are baffled by the inability to >> override from the inventory the variables set by a role (I've googled >> several articles discussing about the topic). >> >> My proposal is to add an include_defaults with the same behaviour of >> include_vars but whose values can be overridden using the usual >mechanism. >> >> The rationale has been explained yesterday: it is not uncommon to >have >> dependencies across roles. If role B depends on role A it cannot use >values >> for variables provided by A unless these values are specified >globally, >> e.g. in group_vars/all. This breaks roles encapsulation and forces >the >> maintenance of larger-than-necessary group_vars files. Using >> include_defaults only B is exposed to the variables whose default is >> provided by A and group_vars files only need to override the more >generic >> values provided by the role as fallback. >> >> I think my proposal is simple and doesn't change radically the way >ansible >> works (e.g. introducing a new level of vars precedence) and totally >> backward-compatible as it uses a new command. Reading the commentary >about >> the topic I think it is a model many people expect and some users >have >> developed their own hacks to work around the limitation (e.g. using >> no-tasks dependencies). >> >> The feature is implemented in my branch < >> https://github.com/dvarrazzo/ansible/tree/include_defaults> and >consists >> of just a new plugin, no change to the tasks runner. It may be >missing >> something or could be designed in a different way (e.g. it could be a >> "include_vars target=default" instead of a new command, or it could >take >> "role=name" instead of a full path to automatically include >> role/defaults/main.yml): feedback is welcome. >> >> I'm happy to know what other users and above all the developers think >> about the feature. Again, thank you very much for the invaluable tool >you >> have provided. >> >> -- Daniele >> >> -- >> 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 [email protected]. >> To post to this group, send email to >[email protected]. >> To view this discussion on the web visit >> >https://groups.google.com/d/msgid/ansible-project/57efe44c-4dae-4356-a014-757074547bfb%40googlegroups.com >> ><https://groups.google.com/d/msgid/ansible-project/57efe44c-4dae-4356-a014-757074547bfb%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> -- Wysłane za pomocą K-9 Mail. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5776e415-1310-4b34-814f-cf149a39e9d7%40email.android.com. For more options, visit https://groups.google.com/d/optout.
