On Wed, Sep 2, 2015 at 12:31 PM, Dan Stillman <
dsti...@gmail.com> wrote:
> I haven't received a response on this, but since I posted it, the various
> variable precedence bugs I've reported have continued to reappear and
> disappear through successive commits. Usually when one is fixed, another is
> broken. One issue [1] was even closed as a "misunderstanding" (despite the
> supposedly correct behavior making very little sense) before being
> acknowledged as a bug (and then being fixed, and then regressing again),
> suggesting that Ansible developers aren't even clear on how variables
> _should_ work. Currently, a number of the bugs (including a P1 bug that was
> previously fixed [2]) are present in devel.
>
> I've provided simple test cases with every bug report and suggested a
> reorganization of the test suite that would allow them to be easily
> incorporated. I don't see any point in continuing to report these — or,
> honestly, in continuing to try to use Ansible — if no effort is made to
> ensure that these dangerous bugs stay fixed.
>
> [1]
https://github.com/ansible/ansible/issues/11996
> [2]
https://github.com/ansible/ansible/issues/9497
We definitely recognize the concerns about variable precedence. Most
users don't have much to worry about, but some users with very complex
playbook structures can run into challenging corner cases with
variable precedence -- corner cases that have become more acute with
Ansible's rapid and somewhat organic growth.
One of the main goals of Ansible 2.0 is to solve this exact class of
problem. In the particular case of variable precedence, we're pursuing
the following design goals:
1. Limit variable precedence handling to a single section of the
codebase. That makes it harder for weird assignment changes to sneak
in. You can find that code in the VariableManager class [1].
2. Ensure that variable precedence is documented in great detail. In
the past, some details of precedence have been less clear than we
would have liked, so we're firming that up [2]. We will continue to
iterate over this definition until we're satisfied that it's correct,
and then we will document it officially.
3. Ensure that variable precedence is rigorously tested. Remember that
2.0 is still in alpha, and regressions should be temporary, so long as
you help us by reporting them. We do have some unit and integration
tests and we are working on cleaning them up, and we welcome more
tests not covered already by existing cases.
4. Ensure compatibility moving forward. Once we have proper
documentation and testing for variable precedence rules, we will be
able to introduce changes with a strong guarantee that those changes
will not break compatibility.
There is one problem that we will not be able to solve for everyone:
in past versions of Ansible, variable precedence has been subtly
different in some cases from release to release. For the vast majority
of users, those differences won't be a problem -- but in setting the
proper precedence behavior, once and for all, we may end up biting
users who settled on a previous version of Ansible with different
variable precedence behaviors. This is why documenting the proper
behavior, and sticking to it, is such a high priority for us -- we
want to ensure that anyone who has to pay a cost for fixing these
issues will only have to pay that cost once.
If you see variable precedence breakage in the 2.0 codebase, please
report it in Github! We can't guarantee that we will have a fix for
your particular breakage in 2.0, but we can guarantee that we will be
able to tell you why it's broken, and what the proper behavior will be
moving forward.
We know that our continued success depends upon providing a dependable
and transparent codebase that can be useful for everyone from the
novice to the power user. That's what the push to Ansible 2.0 is all
about. Thanks for sticking with us as we cover the last remaining
ground.
[1]
https://github.com/ansible/ansible/blob/aeff960d028644c19dd845e51ced14a9bd3709c5/lib/ansible/vars/__init__.py#L46
[2]
https://github.com/bcoca/ansible/commit/06969d92b6c9e429defa9295ce78487df8a7d084
--g
> --
> 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 post to this group, send email to
ansible...@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/ansible-project/55E72474.1020508%40gmail.com.
>
> For more options, visit
https://groups.google.com/d/optout.
--
Greg DeKoenigsberg
Ansible Community Guy
Find out why SD Times named Ansible
their #1 Company to Watch in 2015:
http://sdtimes.com/companies-watch-2015/