Call AdminDashboardGeneralData.refresh_stats at boot?

Dev
1

https://www.pfaffmanager.com/ is pulling information from /admin/dashboard/general.json to get version information. It’s very cool to be able to get this from the UX. Unfortunately, it gets updated periodically, not when the server cranks up, so if you do a rebuild, the information is wrong for a good while (up to 30 minutes) before it’s run again. My plan is to have my Ansible tooling manually call AdminDashboardGeneralData.refresh_stats after a new container cranks up, but that seems a bit silly.

Would it make sense to run that task at boot rather than every 30 minutes? Is there a way that it could update without a reboot? If not, why is it running every 30 minutes? At least I think that’s what’s happening. I have confirmed that running the above refresh_stats will make the general.json update.

2 Likes
2

In general we don’t like to run stuff ‘at boot’. While it may make sense in a single-server, non-multisite environment, stuff gets hairy at scale.

For example, if you have an autoscaling setup which adds/removes servers based on load, every one of those scale events can cause multiple servers to “boot” simultaneously. We wouldn’t want all of them to delay startup while some stats are updated.

We also like to make sure that servers can boot successfully, even if the database/redis are in a readonly state.

For this particular pfaffmanager case, do you have a custom plugin and/or discourse_docker template running on the sites? From outside Discourse, you could trigger it like:

rails runner "About.refresh_stats
3 Likes
3

Thanks. That all makes sense.

No! One of the key principles is that everything is just as it would be on a standard install. There are zero pfaffmanager-specific dependencies. If someone sees here that they should do something like a rebuild, add a plugin, or add an environment variable to app.yml, pfaffmanager will do it exactly as if they knew what ssh was and could type commands. Installs use discourse-setup, upgrades run ./launcher rebuild (or bootstrap, destroy, start for 2-container setups). If Postgres is out of date, the procedures in PostgreSQL 13 update are followed, and so on. A couple things have tempted me to make an optional support plugin, but I mostly want to avoid that. I’m already juggling Ansible, Rails, and Ember–having another piece at play is not very attractive.

But that runner bit was a big help. I’ll just run this after a newly built container is restarted:

docker exec web_only bash -c 'rails runner AdminDashboardGeneralData.refresh_stats'

Thanks so very much. This was just what I needed.

3 Likes