Skip to content
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

tpldir calculation is broken in some cases #56410

Closed
mlasevich opened this issue Mar 18, 2020 · 11 comments · Fixed by #58238
Closed

tpldir calculation is broken in some cases #56410

mlasevich opened this issue Mar 18, 2020 · 11 comments · Fixed by #58238
Assignees
Labels
Bug broken, incorrect, or confusing behavior Magnesium Mg release after Na prior to Al severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Milestone

Comments

@mlasevich
Copy link
Contributor

Description of Issue

Buggy code is here:

template = tmplpath.replace('\\', '/')
i = template.rfind(slspath.replace('.', '/'))
if i != -1:
template = template[i:]
tpldir = os.path.dirname(template).replace('\\', '/')

Short version, if name of the directory containing the sls is contained in sls name, tpldir calculation will return wrong result.

Slightly longer version, it seems to be trying to find the tplpath by looking for last occurrence of slspath in template name - without realizing it may occur later in the full template path.

This can be fixed by simply adding the basename of the template to the slspath - although I am not really sure what is the point of this code - seems like a complicated way to get what you already have in slspath....

Setup

setup as file x/x.sls

test:
  test.nop:
    - name: {{ tpldir }}

Steps to Reproduce Issue

  • if you run the state above, you will get output of name to be . - which is incorrect
  • if you rename that state file to anything without "x" in the name, it will return name 'x' (correct)
  • if you name it anything with x in the name, you will have a problem
  • if you move it to x/x/x.sls - you will get "x" - which is, again, incorrect
  • if you move it to x/x/y.sls - you will get "x/x" - which is correct

Versions Report

bug is still present in the master branch as evident by code link above

@frogunder frogunder added this to the Approved milestone Mar 19, 2020
@frogunder frogunder added Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around P4 Priority 4 labels Mar 19, 2020
@sagetherage sagetherage removed the P4 Priority 4 label Jun 3, 2020
@mlasevich
Copy link
Contributor Author

Any news on this? Still hitting this bug in random places - driving people crazy where things unexpectedly fail

@sagetherage
Copy link
Contributor

@mlasevich there is a long discussion on this and I can put this into the Magnesium release cycle as a possibility of fixing, but I cannot commit unless there is some help from the community to submit a PR perhaps @terminalmage?

@mlasevich
Copy link
Contributor Author

What is the concern? I can take a stab, but I am a bit unclear about the larger context of this function and worried that its intertwined with other things I am not seeing... Thus would prefer to have someone who is more familiar with the code look at it.

@sagetherage
Copy link
Contributor

@mlasevich you are of course welcome to take a stab at it! I was looking through the comments on the closed issue you linked and there was talk of many things, so it seems to have gone in many directions, and yes I also want to be sure you have someone available to look through the code with you, that is my entire intent. I hope that is suitable.

@terminalmage
Copy link
Contributor

I tried to tackle this (or something similar) but ended up breaking behavior that others relied upon. I'll try to dig up the PR and issue on Tuesday. Want to make sure we don't make the same mistakes this time around. 😄

@sagetherage
Copy link
Contributor

Thank you @terminalmage and if @mlasevich you two want to work together I am happy to help set up time and use our Community Slack or Zoom to help facilitate or @cassandrafaris can help as well :)

@sagetherage sagetherage added Community Magnesium Mg release after Na prior to Al labels Aug 18, 2020
@sagetherage sagetherage modified the milestones: Approved, Magnesium Aug 18, 2020
@sagetherage
Copy link
Contributor

I tried to tackle this (or something similar) but ended up breaking behavior that others relied upon. I'll try to dig up the PR and issue on Tuesday. Want to make sure we don't make the same mistakes this time around. 😄

This is the original PR, right? #55434 and this is commit that it reverts 7c28995

@terminalmage
Copy link
Contributor

@sagetherage No, that commit is actually from my original PR (#55434) which was reverted by @dwoz in #56341 per the conversation in #56119 (comment).

Note that the act of reverting added some documentation. If any changes are made, we want to make sure that we are not changing behavior in such a way that it will create further confusion (or conflict with the docs).

@sagetherage
Copy link
Contributor

oh gosh! look at that, I am not correct! Thank you for setting me straight. Yes, I agree.

@mlasevich
Copy link
Contributor Author

Ok, I actually just started poking at it (without looking at the above first) - I think that entire block of logic is way more complicated than it needs to be.

From what I see the core issue is how to determine the "root" of the sls template in tmplpath - and there are all sorts of tricks used to do that - which are source of the bugs - when the reality is - there are only two possibilities here - either it is whatever is in sls or whatever is in sls plus "init" - am I missing something? Are there any scenarios where sls and tmplpath are completely different?

@mlasevich
Copy link
Contributor Author

mlasevich commented Aug 18, 2020

My first stab at it, I need to run out for a bit - may not be ready for a PR yet, but wanted any opinions:

made the PR instead

mlasevich pushed a commit to mlasevich/salt that referenced this issue Aug 18, 2020
dwoz added a commit that referenced this issue Oct 8, 2020
* Cleanup calculation of template sls/tpl context

Fixes #56410

* fix string formatting

* Add unit test that works against old version (with bugs)

* Updated unit tests with non-buggy values and fix found bugs

* cleanup unit tests to test underlying function

* remove old unit test components no longer used

* Cleanup

* More Cleanup

* More cleanup. Add Mock to test.support.unit

* Add changelog entries

* Fix Mockery

* Import order fix

* Handle backslashes in sls names under *nix

* Cleanup

* Make sure we return a dictionary from jinja.load_map

* Fix scenario when sls is empty but present

* Touched another file - Cleanup to make pre-commit happy

* Adding variables to docs

* Fix expected tplpath value to be OS specific and note so in docs

* removing comments from imports as per pre-commit

* removing comments from imports as per pre-commit

* Put slsvars changes behind a feature flag

* Better documentation for enable_slsvars_fixes feature flag

* Fix test that should be skipped on windows

Co-authored-by: Michael "M3" Lasevich <[email protected]>
Co-authored-by: Sage the Rage <[email protected]>
Co-authored-by: Daniel A. Wozniak <[email protected]>
Co-authored-by: Shane Lee <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior Magnesium Mg release after Na prior to Al severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants