Set consistent cache handling time

rjschwei commented 2 months ago

Description

When no specific caching mechanism is configured for Rails the default file cache applies. In this case the expire_in argument for cahce.write is ignored. File cache clean up, i.e. expiry is covered by the rmt-server-trim-cache.service, which cleans the cache after 20 minutes. The cache trim service and the expiry time set in the code had different values leading to different behavior when a different Rails cache is configured. This commit addresses this discrepancy.

Fixes # (issue)

Change Type

Please select the correct option.

[ x] Bug Fix (a non-breaking change which fixes an issue)
[ ] New Feature (a non-breaking change which adds new functionality)
[ ] Documentation Update (a change which only updates documentation)

Checklist

Please check off each item if the requirement is met.

[x ] I have verified that my code follows RMT's coding standards with rubocop.
[ x] I have reviewed my own code and believe that it's ready for an external review.
[ ] I have provided comments for any hard-to-understand code.
[ ] I have documented the MANUAL.md file with any changes to the user experience.
[x ] RMT's test coverage remains at 100%.
[ ] If my changes are non-trivial, I have added a changelog entry to notify users at package/obs/rmt-server.changes.

Other Notes

Please use this space to provide notes or thoughts to the team, such as tips on how to review/demo your changes.

digitaltom commented 2 months ago

The file based cache in conjunction with cron-based fixed cache file deletion after 20min is also the reason that https://github.com/SUSE/rmt/blob/master/engines/instance_verification/lib/instance_verification/engine.rb#L5 is without effect in public cloud.

It would be useful to add a code comment before the lines that use Rails.cache.write, making more clear how cache expiry works in public cloud.

Did you consider using memory or Redis as cache backend to be able to use custom expiry times per use case?

rjschwei commented 2 months ago

The file based cache in conjunction with cron-based fixed cache file deletion after 20min is also the reason that https://github.com/SUSE/rmt/blob/master/engines/instance_verification/lib/instance_verification/engine.rb#L5 is without effect in public cloud.

It would be useful to add a code comment before the lines that use Rails.cache.write, making more clear how cache expiry works in public cloud.

Did you consider using memory or Redis as cache backend to be able to use custom expiry times per use case?

It is my understanding that caching is a general Rails configuration, i.e. config.cache_store= as such this is not a Public Cloud specific item. It just so happens that in the current infrastructure setup we do not configure a specific caching mechanism which makes the Rails cache fall back to a file cache and in that case the expires_in setting has no effect, which is why the scrubber engines/registration_sharing/package/rmt-server-trim-cache.service and corresponding timer engines/registration_sharing/package/rmt-server-trim-cache.timer exist. Meaning commenting here or anywhere where we have Rails.cache.write() exists would make the comments potentially incorrect depending on the Rails cache configuration someone might choose.

In any event based on the conversation around adding registry support we will drop the Rails cache and use our own implementation.

jesusbv commented 1 month ago

Closing in favor of #1140 where all the changes related to drop/remove Rails cache previous system are introduced

SUSE / rmt