Open jperville opened 3 years ago
The bug comes from a combination of how reclass handles references to references and paths to list elements. If a parameter is reference a check is made to see if the referenced parameter itself is also a reference. If this nested reference value has not yet been evaluated then it is evaluated first and then the original reference is evaluated.
This check to see if a referenced path itself needs dereferencing fails for list elements because of an inconsistency in how reclass represents the path to elements in a list. Essentially the type of the index number of an element in a list is set inconsistency, in one part of the code it's an integer in another it's a string. So when the check to see is a reference itself needs dereferencing happens there's a check to see if the path to the referenced parameter is in a set of parameters that have not yet been dereferenced. For references to lists this check involves an equally test of the list element number, this always fails due to the type mismatch, i.e. there are tests such as '0' == 0, which of course always fail.
I'll give this a little thought over the next week or so, but sorting out the type mismatch will fix the issue.
The issue
I tried reclass an inventory with one yaml value referencing another value nested inside an Array and nested classes are involved.
The issue is very difficult for me to describe since I am not familiar with the "reclass" ontology, so I describe it with full reproduction instructions (see below).
I am using the develop branch from https://github.com/salt-formulas/reclass , that is version 1.7.0 of reclass. My system is Ubuntu 18.04 on amd64 with python 3.6 (Python 3.6.9 according to
python -v
).Here is the stacktrace that I get when I run
python reclass.py -b mytest --inventory
in my virtualenv : Running:I can work around by duplicating the indirect reference to use the direct reference everywhere in my inventory, but I'd rather have a shorter and more flexible inventory.
How to reproduce
In my reproduction scenario, the directory structure is as follows:
The files are created as follows:
This finishes setting up the bug fixture directory.
Some tests and comments
Running with both direct and indirect references and the kubespray class imported
Run:
Should trigger the exception reported above.
Running with only the indirect reference and the kubespray class imported
Run:
Should result in a functional inventory
Running with only the direct reference and the kubespray class imported
Run:
Should also trigger the exception reported above. So, does it mean that the indirect reference alone triggers the bug?
Running with both direct and indirect references and the kubespray class commented
Run:
Should result in a functional inventory. Looks like the problem is in the kubespray class, not in the indirect reference !
Running the inventory with an empty kubespray class
Run:
This last example also results in a functional inventory. The bug does not trigger !
Conclusion
The bug occurs when:
kubespray
class is imported from within thekubemanual
classparameters.kubespray.access-ip-using-indirect-item
which indirectly references a value which is located inside an array itemkubespray
class has already definedparameters.kubespray
(even if it is an empty dictionary)The bug does not occur when either:
parameters.kubespray
is undefined at the time the indirect reference withinparameters.kubespray
is evaluated