Fix cached osrelease_info grain type

[srg91]

What does this PR do?

This pull-request fixes problems with operating on osrelease_info grain if it was loaded from cache. Now it loads correctly as tuple.

What issues does this PR fix or reference?

I found the one: #54908

Previous Behavior

loader.py loads grain osrelease_info as list.
It broke modules like aptpkg.info_installed and similar.

New Behavior

Now osrelease_info loads as tuple

Tests written?

Yes, unit.test_loader.LoaderLoadCachedGrainsTest

Commits signed with GPG?

No

[rares-pop]

This seems to fix an effect, but not the root cause of the problem.

Also, if it's a general mechanism that 'flattens' the tuples, are there other cases that needs to be fixed?

[srg91]

This seems to fix an effect, but not the root cause of the problem.

I think it is, because we have the common func which process loaded cache. We can fix it in another way, but it seems to be more complex, because (if I understand problem correctly) it will require to change the store cache engine (from msgpack to something else).

Also, if it's a general mechanism that 'flattens' the tuples, are there other cases that needs to be fixed?

I looked through grains/core.py and some other modules before and found the only that case.

[arizvisa]

Although it might not be the root cause of the problem, when performing an implicit operation that can have different semantics between sets, lists, or tuples, it's much safer to impose the type at the time of use rather than let the type pass through a callstack without knowing what else that type might taint.

Nonetheless, I think it's a maybe good idea to assert the type during development, and impose the type w/ a warning during production to help reduce and track down these sorts of issues. That mis-typing symptom occurs in a few of my other bug reports (#54882 come to mind).

Just my 2cents, and thanks for tracking this down to a caching issue. I literally thought I was crazy when I couldn't repro.

[dwoz]

@srg91 Thanks for the contribution. This change needs to be made against master.

[srg91]

@srg91 Thanks for the contribution. This change needs to be made against master.

Thanks for noticing, I just followed the contribution docs. Could you tell, please, the best way to do this? Is it will be enough if I just force replace my branch and change this pull request or I should create the new one?

[srg91]

I've replaced commit with force push and switched destination branch to master, but forgot to update master before, sorry. I've updated branch to master with merge, but maybe I should do this with rebase?

[arizvisa]

@srg91, not sure if you'll get a response from the maintainers as I asked questions similar to yours before and didn't get an answer to my questin for like a year. But yeah, once you change the branch compare for your PR to master, the commits are a lot cleaner w/ a rebase.

For now though, just wait for the tests to complete before doing the rebase and I think you should be good.

[srg91]

@arizvisa thanks for your comment. All checks are done instead one - ci/py2/centos7 (https://jenkinsci.saltstack.com/job/pr-centos7-py2/job/PR-55796/3/console). I had no abilities to parse exception and decided to just do rebase :) Maybe restart would help, if no I will try check it later.

[dwoz]

@srg91 @arizvisa Yes, it's been a fairly painful transition to master. The updates to the contributor docs have been committed and will be released with neon.

[arizvisa]

@dwoz, if you guys make tags for prioritizing the PRs your community can likely help with some of the small or submitted ones. Maybe something simple like "PR low-priority", "PR high-priority", "PR medium-priority", etc.

Like I didn't know that you guys were going through the huge process of phasing out the development branch entirely and I can at least help with some of the PRs that me or others have submitted so it's less work on you guys.

But again, I hope I'm not speaking out-of-turn for others, but please let us know if you guys need help with porting one of our PRs. Silence makes us contributors feel hopeless and also whiny.