Did anyone observed a breaking change with redis caching?
After updating to ansible==8.7.0 ansible-core==2.15.13 ansible-compat==24.10.0 the hostnames in redis have a s1_ prefix
even if in ansible.cfg i have fact_caching_prefix = (empty definition)
moreover i seen the the content of the fact caching is changed,
now the structure is "{\n \"__payload__\": \"{ ...escaped_dict... \"\n}"
looking at
it does not seem to be something in the actual redis module..
Check out [yaml cache plugin] Error while accessing the cache file 'facts/s1_localhost' with ansible 2.19.2 · Issue #10849 · ansible-collections/community.general · GitHub and the rest of the discussion. That at least explains the content. The s1_ prefix is probably (I’m guessing here) a way to avoid collisions with cache entries created with older versions of ansible-core (and the 1 is maybe a version number that can be bumped in case the contained format changes in the future).
Also you likely have ansible-core 2.19.x, not 2.15.x, since this was only introduced with ansible-core 2.19.
Thank you for information!!!
So, from that discussion it seems that fact caching and it’s usage is basically broken and unusable for hardware inventory in 2.19 series..
Then, i will try to use 2.18.10 as a better version of the native python 3.9 options and wait for better times ..
Just curios: given the change of format, is it still working as cache?
i mean, will the playbooks get the required information from cache instead of getting fresh facts?
on the version that i have, yeah, while juggling with pyenv i lost the track of what i’m using ..
on native alma 9 with python 3.9 i have:
ansible==8.7.0
ansible-compat==24.10.0
ansible-core==2.15.13
while in the py312/py313 envs i have
ansible==12.1.0
ansible-compat==25.8.2
ansible-core==2.19.3
Regarding the s1_ prefix: the 1 is actually a schema ID (and thus basically a version number), see ansible/lib/ansible/_internal/_plugins/_cache.py at 22721b5d63816a270605d071684b0e5b496163cb · ansible/ansible · GitHub.
I wouldn’t say that… it depends a lot on what you want to do it. Caching still works fine when simply using Ansible. But if you rely on the cache having a specific structure, then you have a problem indeed. Out of curiosity, what do you need the cache structure for?
Yes, it should work as before. If you treat the cache as a black box, it should continue to just work. (Except that ansible-core 2.19 won’t be using entries cached by previous versions.)
Thanks a lot!!
i’m keeping a hardware status of the machines (hdd/ssd SMART info, cpu/mb/memory information, network hardware and settings etc) that i can query and check at any time
Hmm, that will not work that easily anymore… You could write code to decode the JSON blob and extract these values, but that might be inefficient or even impossible (depending on how you do the querying) without larger changes to your system.
well, i made it work, but the problem is that arbitrary s1_ which i can only hardcode .. and if this change to x1_ with a new ansible version, then it will break.. and what is difference between s1_ and s2_ and where is this coded? all this seems completely arbitrary to me, and maddening that as user i cannot opt out, or chose what i really need
Is there a way to programatically extract s values and search in redis for “s_value + hostname” ?
Thanks a lot!
There you can find the source of the s1_ prefix.
yeah, sorry if i was not clear : i seen the code, i meant, from what setting
it comes (ansible.cfg) or how can i use this in an ansible command to select something or to set something, or to list all possible profiles.
For my own purpose it would enough to have something like:
ansible get-caching-schema and to get 1
then i can use this to construct a redis cached hostname
also, is this a fixed schema? like 1 is imutable associated with json payload type of schema?
also, now it occurs to me that this schema id is about the format written in the caching endpoint. is there a chance that the old style of json content can be selected by selecting some other schema?
it would be really user friendly to have such configuration toggle in ansible.cfg
There is no setting. This is hard-coded in ansible-core 2.19, and the prefix will only change if the internal encoding used by ansible-core changes (which should only happen in new 2.x.0 releases, and there only if really needed - so hopefully not for a long time).
Configuring the caching schema (to the previous version) is likely not possible since that would break caching in Ansible.
Just as a breif explanation, the cache created from cache plugins is not intended to be a public interface or API. It is an implementation detail of an individual cache plugin, and designed to support the need of use within a playbook execution.
For your usecase, you should probably have a playbook that you can run against your inventory that gathers facts, and then you store that data in a location you want, in the format you want.
Yes i do have a playbook that gather facts! how can i store them in the location that i want (beside what the caching is already doing)? I had no idea how to do something like this other than reading the cached content from redis.
Thanks a lot!
I guess you would need to define where you want it first. If you still want it showing up in redis, the community.general.redis_data module looks capable.
Once you determine where it makes the most sense to store it for the use case you have, which may require changing assumptions in your original code, then you find a module that facilitates storing it where you want, or potentially write a custom module to do it.