We've had the server.site-name in-database configuration for a few releases now, and ansiblecube sets it for new boxes.
This means the time has come to start removing it from the settings files, to eventually remove those settings files entirely.
But before removing them from the settings files, the first thing to get old boxes to have the configuration set in their database.
This commit adds a migration which searches for an IDEASCUBE_NAME in the settings. If it finds one, and there was no in-database server-name set, then the configuration gets set to what was in the settings file.
Once a box will have been upgraded to a release including this migration, then we can remove the IDEASCUBE_NAME option from their settings file starting with the next release.
This is long overdue, but better late than never.
After this, we can start removing more things from the existing settings files.
And possibly even remove some settings files for some boxes, if that's the last thing they had in it.
I originally thought about making a management command which ansiblecube would run after an upgrade.
However, I figured a migration would make it easier to know which boxes have made the switch:
- with a migration, we just need to look at the Ideascube version on the box
- with a management command, we would need to go through the ansible logs to figure out on which box the command has been run
I'm not entirely happy though, as I think this would be better suited for a management command, since that's a one-time thing to run, and a migration would have a (minor) overhead forever in the future (e.g when running tests, creating a new box, etc...).
I'd be happier with a management command, if we can find a simple way to know whether the command has been run for a box. Any idea?